I did add the slides online because we had a couple extra minutes. There are a couple of code examples for the most part. We're going to be talking conceptually about things that are happening here. So this session, in case you're in the wrong room, is about plugins, composer, and PHP 7, which you can probably tell from the title slide. I am Chris Vanderwater. So I have been doing Drupal for about 12 years now. In that time, I've helped maintain C-tools, contributed heavily to Drupal 8, really focused my time and my effort into doing a lot of page layout work. But for the content of Hock, and it's one of the plugin subsystem co-authors, and so I influenced it very heavily. Also, if it's not obvious, I worked for Acquia, and they helped me be here today. So in order to have a proper discussion about the plugin system, we should first understand what plugins are. And I've had a long time to try to come up with an analogy for what plugins are. So in case this is new to you, or in case it has never just made sense, we're going to try out a new analogy today.  But it's relevant because lightbulbs are the analogy. There are lots of lightbulbs in the world. There are LEDs, there are fluorescence, there are incandescents, and there are all sorts of different sizes. But you can plug lots of different sizes into, say, a fixture in your house. So keeping with the analogy, if we have a house, maybe say a Drupal house, then fixtures within your house would be anywhere that there's a plugin system. So going to raw Drupal for a second blocks as an ideology or a fixture within Drupal, and conditions are a fixture within Drupal, and input filters are a fixture within Drupal, and they all have different kinds of bulbs or plugins that could just be screwed into them and swapped and used. This is the very idea of an interface. Screw it in because it fits. It only fits that. It wouldn't fit something of a different size. So hopefully this seems sensible, but it's worth noting for purposes of this talk that there are a lot of other houses out there. Ours is not the only one on the block. I want to call this out up front because I think it's really important to the conversation as a whole and to us as a community. So I've got a big question mark up here, I guess mostly because of the history lessons that I'm about to give. When we started writing plugins, we did so because we couldn't find anything else like it anywhere in the PHP world. And so we set out to build something that seemed kind of new in a lot of ways, which is sort of strange to say out loud, like everybody's been programming everything for a very long time, it's strange to find things that don't already exist. But at least for purposes of what we needed, we couldn't find anything like this. And so the question was like, why hasn't anybody done this yet? Now it's worth noting, let's see, when we wrote the plugin system since we hadn't found it anywhere, we really wanted to share it with other people. And so because of that, the plugin system in Drupal 8 was actually the first component. If you're familiar with Drupal 8's actual code base, there's a Drupal component library that has code that ostensibly should be reusable to people not Drupal. Plugins was the first thing to land in there. We were the first ones to really say, this is something we want to see done. And so we went and did it. Unfortunately, attempts to make plugins exposed to the rest of the world have largely stalled. And this isn't like due to any one factor, it's just we've written a lot of code, Drupal as a whole. We have a lot of code to maintain and getting our components out there where other people could make use of them just has not been that big of a priority compared to killing critical bugs, right? And this is understandable. It's unfortunate, but it's understandable. And yeah, I've got the IDs for a couple things up there. So if you wanted to go look at this, it's like a five-year-old issue, I think. So it's worth looking at and reading through and seeing where we're at. It's actually a pretty short issue. Truthfully, I believe that we will eventually get there. I've even had talks this week about what it would take to do it and I think it's something worth doing. But it has not been done yet. So to that end, I want to point out a couple of things. Plugins has been around for a while. This is the issue where plugins was originally committed to core. You didn't work with anything in Drupal 6 that long if you've worked with Drupal 6. And most of the modules that you've worked with, they iterate more quickly than once every five years on the code that you're using in there. So it's worth noting that when this went in, it became the foundation of all of our info hooks, not all of them, but the vast majority of the things that were info hooks in Drupal 7 converted to this. We've had a really, really long time with plugins because it went in early in Drupal 8's life. It was, at this point, one of the first things to really land. And since it's been around for five years and we have done so many implementations of it, there have been a number of things that have been kind of tacked on over that time that I at least took great issue with. So some of those things would be like how we chose to do dependency injection from our container and my own experience with object orientation when we wrote it to begin with. So I think my point here is really just that the plugin system is kind of ancient technology in a lot of ways. I know it's new to a lot of people, maybe even in the room if you've only been working with Drupal 8 since its release. But even at that we just did 8.3, which is the fourth release of Drupal in once every six months. Okay, it's been out for a couple of years. So let's see. Just to belabor the point a little bit, when we built the plugin system, anybody want to guess what version of PHP we were running against? 5.3. Yeah, we wrote it against PHP 5.3. Now a lot has changed since then, a lot of language features and things like that have come along. Things that we didn't and couldn't make use of at the time. So kind of between a half decade of working with the system and a half decade of PHP running ahead of us and continuing to get better and better and better, I personally felt like it was really time to revisit the plugin system and just rewrite it from scratch on all the same basic concepts. So to understand some of the changes that I've made here and what they entail, it's important to understand the things that really irritated me about the final product in D8. And so in no particular order, these are static factory methods. Let me just see. Who in here has actively worked with Drupal 8's plugin system? Okay. So just so I know who I'm addressing are a lot of people in here mostly because this is like the PHP track and you want to see what Drupal's hopefully sending back to PHP. I'm getting some head nods. Okay. Well, you're in the right room. Cool. Well, then I will fly through this a little bit and we'll kind of talk about it as we go. But for those of you not familiar with the plugin system, it has a static factory implementation on it, which would make sense in a lot of other places but it doesn't make sense for reasons that I'll go into here momentarily for the plugin system. Also, constructors, as I mentioned, when we wrote the plugin system initially, it was not my first foray into object orientation, but it was very early into it. And so expectations around what sort of parameters had to be passed to a plugin were kind of explicitly defined as part of what we built. And that turned out to be really problematic throughout the entire Drupal 8 lifecycle. In addition to this, we use arrays for almost all of our definitions of things when objects would have sufficed. And again, I try to be very clear about whose fault this is. It is mine. Because I couldn't even conceive of dealing with them as objects at the time I was so new to OO. Additionally, we have a couple of instances where we don't necessarily always want all of our plugins, and so an idea of plugin filtering really needed to be brought up high-level in the system. And finally, something I refer to as plugin mutating, which is the notion that... All right, actually, I'll explain this since a lot of people in the room don't have experience with it. In fact, I'll explain the whole point of it. In Drupal 7 and earlier, we used big arrays for everything all the time. So if we had a whole bunch of things that you could use with some sort of metadata attached to it, like, say, a human readable label and some description of something, there was a key with those data elements attached to it. And so when you have a big PHP array, it can be quite tempting sometimes to have a table somewhere that you want to address and then just build a for-each loop in the middle of that array and add stuff to it. You can't stick a for-each loop on a class annotation. You can't stick a for-each loop inside of a YAML document. Like, these are not things that you can really easily do, but we needed the capability to allow a single definition, a single class, to have multiple instantiation mechanisms with different sets of config basically passed to it. And so we came up with this idea of derivatives, which actively changes what plugins are available by expanding the library based upon some other class's knowledge. So when we talk about derivatives, just think it's a for-each loop to make one thing act like many things. That's all it is. Luckily, I've had five years to come up with that definition. Hopefully it was okay. The other thing we do in Drupal all the time on this is Drupal's really famous for alter hooks.  And that's really useful and also very dangerous. So we have to have kind of an approach to doing that that is sensible within the plugin system. So with that being said, I wanted to rewrite it on PHP 7. Truthfully, I found more of the features of 5.6 to be what I actually needed on a day-to-day basis. So bare minimum, I had to have 5.6, but I went full bore all the way to 7 as I was rewriting it and used a number of features of it which we'll talk about.  So the first is this notion of the static factory. For those of you who maybe don't have experience with static factories, I came up with this as my graphic for what it is. So if you consider the beige here, all-to-be classes, in fact, they're all essentially the same class. They have all the same code except for one method. One static method that knows how to instantiate itself. And Drupal uses this all over the place. We use it for route controllers. We use it for a number of different things where rather than, say, document something directly into our dependency injection container, we let the class document it itself and then just pass the container to it. Well, the plug-in system went in so early, there wasn't even a dependency injection container in core yet. So of course, we made no allotments for it. Or they happened close to the same time, something like that. It was very early days. So when we started running into plug-ins that really needed services from the container, this was introduced pretty early on as how we would do it. I took great exception to it, though, because it means that in order to get another plug-in with different dependencies, I have to subclass the original class every time. And that means that I probably need to stick a new annotation on this class, and even though everything's the same except for the dependencies, I have to do an awful lot of work to get there. And moreover, it tightly coupled dependencies with the class, which a lot of people have grown to accept and I still have never really accepted it. I dislike it. So the new plug-in system works a little differently. We just have a single class definition, and we go ahead and we document factories that can be used for them. Now, saying that out loud, I guess I want to be really clear. Most of the plug-in system operates through an annotation on the class. So this is still tightly coupled. I said this factory class is what you'll use to instantiate yourself, right? So initially, this seems hypocritical. All I did was kind of rearrange the chairs. But if we go back to this notion of altars in Drupal, if you want to think about it like event dispatching or something, if I were to hand all the definitions around, someone could actually subscribe to it, say, I want this definition and let's copy it, change its ID, change its factory. Everything runs through the same class. They just have different factories on there, and I get totally different plug-ins out of it, which means that the behaviors, of course, all the same, because it's all running through the same class, but I can pass a different constructor argument to it if I want. Hopefully, let me check my notes and make sure I didn't totally go off rails. Yeah, no, that's basically it. I'll have a time for questions here after this. But if I'm explaining something and it's like, no, raise your hand and we'll address things as we go. So with that, I'm going to move to the topic of the constructor. Now, this was actually one of my favorite things about the rewrite because we got to leverage some of 5.6's language-level features in order to solve some of this. But in order to understand it, I want to give kind of a clear picture of how Drupal 8 worked for this. So Drupal 8 plug-ins classically have to know three things. First, they have to know what their configuration is. And this is actually almost optional in a lot of instances within Core, and you'll see why in a minute. But they absolutely had to know what their plug-in ID was. And a plug-in ID is just a machine-readable string that identifies the class. It's like rather than needing to know the class's full name in order to instantiate it, if you know that it's called foo, you can just tell the plug-in manager to instantiate plug-in foo, and you get a class back. It also needed to know its plug-in definition, which the system could look up from its ID, but your class, your plug-in, was given all of this information all of the time. So if you found yourself in a situation where you needed more information than this, you probably ended up using config as a dumping ground for all the things, which to be perfectly honest is why I put it there. It was suboptimal, but it was what we had, and again, the degree to which I understood PHP and OO at the time really limited what we could do, because I was one of the driving factors early on here. I just want to acknowledge that doing this kind of sucks, like a lot. The component, by contrast, actually has no prescribed constructors or parameters of any sort on it. We make no assumptions that you're going to pass certain things through the constructor. We didn't even write one into the base class. That, of course, means you need to write your own constructor. And subsequently, it also means you're going to need to write your own factories, which is part and parcel to why the code base, if you go and look at it, is actually quite simple. So I mentioned 5.6 and language-level features that made doing some of this easier. And so first on this is variatics. Who in the room has used variatics? Two people? Okay. So who in the room has used funk-get-args? Ah, okay. That seems right. Did you like funk-get-args? Always seems like a hack. Okay. Well, variatics are in many, many cases essentially a replacement for funk-get-args and a really cool language-level one. They are way better. You can even do things like type-hints, the type-hint, these sort of parameters that are going to be passed into a method with variatics. I'll show some code here in a second that I blew up really big, so I hope everyone can see it. But I want to talk about the opposite of it. So if variatics is making it possible for you to pass in number of things to a method, then, or have in number of things passed to a method, then argument unpacking is the opposite. It passes in number of things to a method. Who in here has used call-user-funk-array? If you have done any work in Drupal, Drupal basically only exists because call-user-funk-array exists. We could not do what we do without it. So as I said, it's essentially the opposite of variatics. It's kind of like exploding an array into top-level parameters of a method, okay? And I already mentioned call-user-funk-array. So is that code awful? Can people even begin to see that? Yeah? Okay.  That means I can pass as many things to this method as I want. I have to pass a definition, and then I can pass as many other things as I want. And all of them will get dropped into dollar constructors. It's actually really nice. You can even do things like type-int it. So in this case, I'm saying all the things passed to this method, however many of them there are, they must all implement foo interface. So rather than iterating over an array of junk that you got out of funk get-args and making sure that they all implement the interface you care about, language-level type-int, done, done, done, right? This is super, super useful stuff. And this is sprinkled throughout the plugin system. I'm going to make the point that what you're seeing here, the top method, is a truncated version of what we actually use to instantiate a plugin. We pass the definition to it, however many constructors were passed to us. We also pass to it. And of course you can rewrite all of this, but this is what we're doing by default. And it really means that if you have a given class that needs like five or six things passed to it, you can absolutely get away with it even though all the other classes only take two things or whatever it might be. Who in here is actively using PHP 7? Of those of you actively using PHP 7, who's using typed returns? Okay, trying to. All right, typed returns are awesome. In Drupal, we document the code as heavily as we possibly can. And so a lot of this ends up being that, you look at your doc block and it says, at return and has some interface or something like that. Hopefully it says something like that. In PHP 7, you don't have to do that. You can actually go ahead and just tell the method itself what kind of thing it has to return. That can be scalar, it could be a string, it could be an int, it could be an array, it could be an interface of some sort, which is really great because it blows up if it doesn't return that. And of course if it didn't, something else that was depending upon its return value would blow up when it tried to call a non-existent method. So this is really nice. Invariably, I have to love on PHPStorm a little bit because if you write this out this way and then go add your doc block, it'll auto-add return statements that are right to your doc block for you, which is pretty great. So worth noting, typed returns are a thing. They're awesome. Of course you need to use them in the right circumstances. They could be used wrong, but take a look at them, learn them, love them, they're great. Let me check my notes here. Yeah. All right, plug-in definitions. For those of you who haven't used the plug-in system, I keep talking about this annotation. That is what we mean when we say a definition. It is literally like metadata about the class. It resides with the class, and we can go and find this stuff. So in Drupal 8, I've already mentioned a couple of times that my inexperience was very much showing when we wrote the definitions portion of it, especially because it all ended up being arrays. Objects are technically supported within the system, so we have the new layout plug-in in 8.3. Layout Discovery has a layout plug-in that comes with it, and all of that stuff is actually doing object-based definitions, and it's great. If you ever deal with entity-type definitions, they're also all objects, which is great. They're the only two plug-ins, plug-in types out of like 40-some odd plug-in types in core that use objects. The rest are all arrays, which is really sad to me. We have Tim Plunkett to thank for the fact that this is even doable because he spent the time to get it working, so it wouldn't even be possible without him, but it was kind of a bolt-on feature that was added after we wrote the plug-in system. And this is super frustrating since you have to actually write an annotation class and you get arrays.  So this is really kind of irritating. Has anybody in here worked with doctrine's annotations at all? Oh, that's more than I expected. Okay, so we're dependent on that system. We're using it, for those of you familiar with it at all, you know, it does the same sort of thing. Unfortunately, Drupal 8 ejects the object and just stores basically the key-value pairs. So this was the kind of problem that we really needed to just solve by writing it appropriately in the system to begin with. There weren't any if, ands, or buts about it. We just had to sit down and write it properly. So we do objects by default because this is probably the 99% use case. Most people don't need an array as their definition when dealing with metadata. Having an object with actual methods on it that you know how to deal with is kind of nice. And PHP supports dealing with objects as though they're arrays, so I can have my cake and I can eat it too if you really wanted to deal with it as though it were an array. You just implement the appropriate PHP interfaces and move on with life. I don't think I have to say that objects are nicer to deal with than arrays. It's probably something we can generally agree on in most circumstances. I said that already. Okay, so we're kind of into the guts of what's new in this as compared to Drupal 8. So I'm going to continue with the Drupal 8 analogies for those of you who have that background, and I'll try to keep it lively for those of you who don't. So in Drupal 8, we have a need to filter our plugins. So we have some big set of plugins, and we need some smaller subset of it under certain circumstances. A great canonical example of this is the context system. So for those of you not familiar, Drupal 8 has this idea of plugins that require context to operate. They say I can only operate in the presence of a data object of this type. So in Drupal terms, that's like a node or a user, something like that. So if I wanted to display the field value of a node, well, I can't very well display the field value of a node if I don't have a node. So we can actually filter what plugins are available based upon what contexts are available. And we can say, like, oh, if you don't require a context, then you're in. And if you do require a context of this type, then you're in. Otherwise, get out. Unfortunately, only Core could have done this because we hard-coded it as its own thing into Core. So anybody else who needs similar but different functionality is going to have a really, really hard time implementing it. In fact, so much so that even Core has this problem in other, like, edge cases. We have this notion of custom blocks, which are their own kind of entity. And every time you create one of those in Drupal, it creates a new plugin definition for it so that you can reuse that block, which at first glance sounds great. But when you realize that when you hand Drupal to a customer, and they go to a page and they just want to, like, add an image to that page, they use this system to do so, that image is never meant to be used anywhere else ever again in the customer's mind. But now it's in their list of plugins that they might want to place on the page, a list of blocks. And so if they do this, like, a thousand times across 100 pages and have, you know, 10 custom blocks on every page, they have a thousand new plugins polluting their user interface. I think that that's bad. And so I maintain a lot of the modules that touch on this topic tangentially, and we've worked really hard to begin fixing it and are close to a fix. But had we had the ability to just filter things in some meaningful way, we might not have had to go to all of the effort to do that. So as part of the rewrite, I included filters. So filters inside the PHP component are just a custom class. They're a class that knows how to filter things. There's actually some talk of just making them callables and running them through array filter, so that you just have a group of callables you can pass. We can do multiple filter passes on this stuff. So to go back to the example that I've used, that'd be like asking for all of the blocks in the relevant context that are considered reusable, right? Those are two filters that operate on completely different axes of information, but they filter the list of plugins appropriately. And so I also want to point out for you PHP heads in the room that Drupal exposes an awful lot through the UI, and plugins is intended to help expose those things through the user interface. So if you want to begin building user interfaces for your non-Drupal PHP components, this is a really great place to start with that sort of stuff, rather than just having some config file where you hardcode what you want to be available, which is what things like symphony might do with bundles and that sort of information, right? And we can filter it on demand, too. So what that means is that every time I want to get a list of filtered plugins, I can pass it a different group of filters. We're going to see another couple of examples here, using variatics. So if that didn't make sense earlier, you'll see it here. But you can see, like, I have a filters array. Can everybody read this okay? Okay, I have a filters array here where I'm instantiating filter one, two, and three. And then I pass this off to the discovery component of the plugin system and say, hey, get me a filtered list of plugins, given these filters. And that dot, dot, dot annotation on top of, in front of dollar filters there, that's your argument on packing. It is functionally identical to this code, okay? In which I made a filter one, filter two, filter three variable, and just passed them as commas to the method. So if you haven't used variatics or argument on packing yet, I'd really, really encourage you to go and play with this. Questions before I move on? Or is that all, like, kind of, yeah? Um, you could just call that method with two different filters once each time, and then do, like, your own array intersects or things like that. Is that, okay, cool. So plugin mutators. I've spent a little bit of time talking about plugin mutators already in terms of derivers and alters, these kind of crazy things we do in Drupal. So derivers said that, alters said that. So when we did this in Drupal 8, we attempted to implement it via decorator pattern, which seemed really, really cool to all of us OO newbies. Didn't work out so well. So we ended up rewriting it with just, like, hard-coded expectations of what should always happen, and then people could opt into those things that we, as Drupal, thought they should be able to opt into. These aren't the sort of things you can do when you're writing a PHP component necessarily, though, because you want people to have control over what it is that they're doing. Ultimately, it's worth noting that this problem was an order of operations problem, and any developer who came behind us, if they didn't get the order of operations exactly right every time, would have gotten really weird results. So in the component, I rewrote this all from scratch and just said, like, derivers are gonna be part of what we know about at the base level, and on top of that, we're gonna take the system that uses that and open it up to everybody so that you can define your own mutators as part of your dictionary, right? When you're saying, I have this group of plugins that I care about and I want, these are the types of mutations that are going to be able to occur on them, and so you can kind of opt into that. Let's see. Yeah, I said that. Oh, so, no, I didn't actually. So a mutator actually operates on the whole set of definitions simultaneously.  It gets all of the new ones, mutates it further, hands it to the next one, and so on and so on and so on. So it can be like a really powerful way, again, the drivers are like the for each loop sort of thing. Alters are essentially, imagine taking all of your definitions, dropping them into an event and dispatching that event to anyone who wanted to make a change to the list of plugins, and this is the list that'll be cached, right? This is the list that everybody during runtime operation is going to see from that point forward, and so it can be a really powerful way to let people do things like change what sort of strings appear in the UI, swap out classes that they actually want to be executed in their case. So you might have provided a plugin that does most of what they want. They subclassed it, added some extra functionality, and then overrode what class was to be instantiated when you asked for that plugin, right? This is a really powerful paradigm because in Drupal terminology, it means that if you already have a plugin active, you can swap what class is running for that plugin with a simple cache clear, and now it's running through your specific code base. Example of this being like blocks. If you had the user login block on the page and you wanted to make a better user login block, you could extend the existing user login block, make any changes you wanted, and use an alter hook to put your own class in as the class that gets executed. Super, super powerful stuff, and with one cache clear, simultaneously anywhere that the user block, the user login block had been used. Derivatives are implemented by default. I don't expect anybody to probably be able to read this. No, or do I really care that you do read it right now. My point for putting it here is if you're looking at the slides later and you want to actually see how this is done, this is an example of the one mutator we ship with, the derivatives mutator. I mean, it's not that many lines of code, it's actually pretty small and straightforward, and so this makes dealing with all of your plugins simultaneously actually pretty easy. Terminology, this is really only for those of you who have used the plugins system in D8, so I will fly through it, literally. There are like five new terms to really know, and some of this you have to kind of know the old terms. We used to call things managers. There's not really a pattern in any programming anything that I know of that's called a manager except for plugins, and so it's difficult if you don't know what we're doing to look at it and go, oh, that's a manager, I know what that is. No, you don't. It's not a thing, right? So I changed some of the terminology. I used the word dictionary because I spent five years looking around and that seems to be what it is. It's a dictionary with an attached factory. Okay, that's plugins in a nutshell. So, or a library, however you want to think about that. In Drupal 7 and Drupal 6 we had this notion of plugin type which is really just like how we addressed it. It was a string so I keep talking about blocks. It'd be nice to be able to ask your plugin dictionary what type of information do you hold and it could say, oh, it's block information. So we added that. It's a nice to have. But then we have Sets which are the set of definitions, right? We have filters which we've already talked about and mutators which we've already talked about and so just kind of having the basic knowledge of what these are is good going into it. So, let's see. So, why did I propose this talk? Some of you are probably asking yourself that question at this point. I did this for two reasons. My first reason is that I feel like the component is actually reaching a level of maturity that is worth at least beginning to compare it to what Drupal 8 does. Begin talking about Drupal 9 or Drupal 10 and hopefully begin maybe reeling some other people into it who want to use it outside of Drupal completely.  The second reason I'm doing this talk is because I feel like there's a really significant opportunity for the Drupal community right here that we have not yet taken advantage of and not in the plugin system itself but the plugin system is kind of representative of the opportunity to a certain degree. And that opportunity is around decentralizing our code base and sharing it with the rest of the PHP world. Does anybody know how much of the scripted web runs on PHP off the top of your head? Yeah, 82 is the number I traditionally hear. What's the number that Drupal is? About one to two is what we debate over. If if we were to take APIs that we knew and understood and make them publicly available to the rest of the PHP world we could do Drupal outside of Drupal when we're not Drupaling and we could get a much bigger part of that other 80 odd percent we are not currently a part of today. Right? You become an expert in one of these APIs and it's like having a whole different career all of a sudden. There's a zero and some involved. Right? I'll get back to that. Component maturity. Kind of like as a supporting point to my first point here I've done three completely different implementations of the plugin system. And I wanted to have some videos ready for this just to kind of talk over while they were playing in the background. But I was running at breakneck speed to get here for this after finishing my slides. So if anybody wants to see those things you should feel free to come up and talk to me afterwards or online. I will make sure that you get a demo of the things. But the first is a little project called Hedron. And Hedron is a tool of my own making because I'm kind of irritated with all of my local development options right now. So I started writing which is a PHP and Docker-based utility for spinning up completely new Docker instances with whatever sort of code base you want on them. For those of you who've maybe used something like PlatformSH or something where you're largely dealing with like a composer.json file and you can just kind of push it and it builds your system it's sort of like that except it has your entire Docker stack with it. So you have to fork or branch the system and change your Docker stack and when you push it push to get it recognizes that you have changed these things and spends up an entirely new environment installs your code base on it gets it up and running and now you have two completely different Docker groups running like Docker environments running and it goes what commands to fire in order to bring it up and it's still very early in its stages but it does things like support project types so you can do something like say I just want to manage this purely and get I'm going to give you exactly the files I want and you just host it properly and it sets it up with like InginX or Apache or whatever it is that you want it to be doing from your Docker config and just builds the thing out for you and you just have a really minimal composer file that says oh this version of Drupal 8 and these modules and then it stands up all of that for you inside of your Docker environment. So Hedron is kind of a pet project that is nowhere close to ready for prime time but is out there where people can play with it it's hedron.sh if you want to look over my shoulder and see how badly I'm screwing up go for it. But yeah it uses the plugin system to define different project types so like Git, Magento, Drupal, raw composer you could do all of these sorts of things and then it uses plugins in a separate subsystem within it to define what the workflows of each of those projects are going to be and what the individual operations you might want to do at any given step of say building up a Drupal site or a Magento site or something like that becomes a really powerful way to define your own workflows for building projects. Second is a little did I miss an M? I might have missed an M Second is a project called Communicata that my cousin and I have been working on and so my cousin sat down to write a Discord bot one day and he hasn't been working with OO to the same degree I have so I came alongside him like a month or two later and said like oh this is cool can I rewrite it in plugins and he's like yeah sure so I did and now we have a Discord bot that you can add functionality to just by writing different composurable libraries and saying like oh I want the bot and that library and that library and that library and now you have a custom bot that only responds in the ways that you composed components in because for each individual composurable component you can define what plugins are available in there and the plugins all, I mean they're just using regular expressions to figure out what people are saying and whether it's something they should respond to or not and then have basically a method for building up their response whatever that might be but it's kind of a simple and elegant solution to building a bot that you can compile however you want you can compile what sort of reactions that bot is going to have again very new only wrote it in the last like month or two just happened some fun just showing that different things are possible my last example here is actually something that we're using at Acquia and we haven't open sourced it yet my boss and I are both going through the effort of trying to make that happen right now but my boss is Cash Williams some of you may know him he's been in the Drupal community for a long time awesome guy he does a lot of performance testing for Acquia and a lot of that ends up going through Jmeter now I won't say what Cash says about Jmeter because it's not fit to be rebroadcast but the point is he likes it and and it kind of sucks so if you've ever used Jmeter it has a user interface that has a tendency to crash I get some chuckles some people have used it okay so he came to me and said hey I want to stop using the user interface I said okay and then I built the plugin system and I went back to him and I said hey do you want to actually do that and so we started spending some time doing it and now we have a system that implements maybe 20% ish of what is available to Jmeter but it's like the 20% he needs to do his job and it's very clear how we did it so adding new things to it should be relatively straightforward all plugin based and it's basically just this large stack of plugins that generate an XML tree but they have a whole configurability notion built into them so that he can configure exactly how Jmeter is going to react to any one of those components and it knows what the XML output is going to be for that stuff so this gives him the opportunity to have PHP code that does 90% of what he needs from one test to the next and he can just change out a couple strings hit the button new XML file yay he doesn't have to import an XML file into Jmeter risk it blowing up on him while he's editing those handful of strings and hit save and hope that everything went okay so the next thing is about a whole new other set of possibilities which are that you could begin to build Drupal, Magento, WordPress whatever extensions on top of this that already script together your notion of things that need to be done in order to say do a Drupal login or do a Magento checkout or something like that like you could have individual commands that you build that are just a group of commands inside of them and you perform that operation and so it opens up the opportunity to build libraries on top of Jmeter and PHP where one or two commands could have taken hours under normal circumstances to get them set up the right way it's really cool, really like kind of interesting opportunity that we've not begun to explore because we're only like 20% in but it's there yeah I guess all of that to say I'm using it in production in a couple of places you know, for some value of production it works I have a lot of test coverage I screwed up my code climate integration so it says I have less test coverage than I do and we haven't figured out how to solve that particular problem yet but even at that it says I have like 75% code coverage on the plugins part and 100% code coverage on the annotations part and it's a lot higher than 75 I have some really good test coverage for this I have a lot of tests written the code is fairly well trodden at this point if you're interested in trying it out I have a bit of documentation on the plugins system and I'm still lacking docs on the annotation system I will attempt to fix that tonight it's usable it's kind of like Drupal outside of Drupal if you've been writing plugins within Drupal these plugins look like Drupal plugins very little difference so this is going to bring me back to my earlier point about let's see I got a few more minutes this brings me back to my early point about decentralizing and sharing our components and what that actually means I said some of this already but I got up on stage let's see two and a half years ago at Drupal Amsterdam and gave a very similar talk I didn't have the plugin system yet I was thinking about doing it but we were really just releasing Drupal in some ways we were right on the precipice of releasing Drupal 8 so I didn't want to go debase what we had already just done with some new system that was new and better and PHP 7 wasn't to a state that I was going to go and just use it yet but I stood up on stage there and gave this notion and so I'm going to actually read direct from my notes because I want to say something very specific here and it's about how Drupal is an open source project doing what I'm doing here it really draws a few things into question and so I want to try to answer what one of those questions is and I think it's that so many people think of Drupal as like a FOS project or they think of it as a product that does something that they need or it's a PHP framework right we've argued about this for at least the last 10 years or so definitely since Drupalcon DC and there was some before that this has been an issue that people have talked about small core people have talked about large core we seem to be going to large core route these days and so I just want to point out that we do this because Drupal it's so many things to so many different people we all use it really differently I know I certainly do when I have conversations with somebody about something I think Drupal should do most people scratch their head and look at me like I'm crazy and I might be but that's a different point but we talk about Drupal a lot and something I think we often miss is that the most important aspect of how we speak about Drupal is the thing that it has in common we keep using the word we because the code is not Drupal we're Drupal okay if we take some component of Drupal and pull it out and make it available to the PHP world we didn't lose anything we gained a lot of things in fact and one of the things we could genuinely gain from that is more community because discrete usable parts of code have a tendency to bring in more developers who might not have looked at something that's like a stack of code this high right if I hand you 40k and you look at that if I hand you 21 meg no one looks at that okay so Drupal is a community not a code base we already maintain hundreds of different code bases not one because we maintain everything that's on Drupal.org all the projects and there are a lot of them so I think my conclusion to this is that Drupal is awesome PHP 7 is also awesome I can say from personal experience that using plugins outside of Drupal is also awesome and I think that if we were to do this to many other Drupal APIs that too would be awesome so I'm wondering whether or not there's any blockers to making this happen because I think this is very important and we should very much consider doing it. I'm going to open the floor for questions at this point I know I've thrown a ton of stuff out there and I took a really hard right turn in like the last five minutes so questions, comments, concerns floors open no as I said I will do my best to provide demos on demand although we are on a limited internet connection right now so if anybody would like to talk to me afterwards you're free to do so please keep in mind that we do have contribution sprints on Friday and that's for most of the day nine until six with a mentored core sprint in the morning and also a first timers sprint in the morning and also the feedback that you give on people's presentations is used to help figure out what we're doing at the next Drupal Con so if you liked me please say so, if you didn't I love you anyway thanks everybody if we already do oh I thank you Cash Williams for showing up thank you


In the previous videos, we have been introduced to what coordination compounds are and we have also seen the various terms that are associated with the coordination compounds like the coordination entity, oxidation state, ligands, coordination polyhedra and so on. It is now time to familiarize ourselves with their naming conventions. You see, naming of coordination compounds can be very complex. In fact, coordination compounds themselves are quite complex. We have different types of ligands, we have different number of ligands and sometimes we have mono-dentate ligands, sometimes we have polydentate ligands and so on. And therefore it is absolutely essential that we come up with a set of rules that can help us distinguish one coordination compound from the other. So by simply looking at its name, we should be able to figure out what the central metal atom is, what its oxidation state is, what are the different types of ligands, whether ligand is a polydentate ligand or a mono-dentate ligand or an anionic ligand or a neutral ligand, etc., simply by looking at the name of this particular complex, okay? So if you are ready, let's quickly look at the rules that we need to follow while naming a coordination compound. Okay, so the first rule is that we first name the catnion which is followed by the name of the anion. For example, here we have CONS36Cl3 and CL3 is the anionic part and CONS36 plus is the catnionic part. So in this particular coordination compound, we will first name the catnionic part which is this coordination entity and then the anionic part. Now the coordination entity need not always be the catnion. For example, in this particular coordination compound, the catnion is a counter ion which is K plus and the coordination entity is anionic complex, right? Now in either case, in either of these cases, the important thing to remember here is that in the naming, we will always name the catnion first. It can be the coordination entity or the counter ion. It doesn't matter. What we need to do is simply name the catnionic part first and then the anionic part. Now within the coordination entity, we will first name the ligand and then the central metal ion. So as we saw before, the coordination entity can be anionic or catnionic as we can see in these two examples. But in either case, when we go about naming the coordination entity, we will first look at the ligand and then the central metal ion. So here the ligand is hydroxy group and the metal is zinc and here we will first name the ligand which is ammonia and then go about looking at the name of the central metal ion. As we already know, the ligands can be of different types. Some are anionic in nature while the others are neutral molecules. So obviously depending on the type of the ligands, their naming would also differ, right? So now let us quickly look at the naming of the ligands. When we have anionic ligands, the name will always end with an O. For example, when we have chloride ligands, the name would be chlorido. When we have bromide ligands, it would be bromido. And when we have hydroxy group, the name would be hydroxo. Now it doesn't really matter if it is a bidentate or a polydentate ligand. As long as we are talking about anionic ligands, the names would end with O. So here are the names of some of the anionic ligands. Let's now look at the neutral ligands. The names of the neutral and cationic ligands are the same except aqua for water, amine for ammonia, carbonyl for CO and nitrocell for NO. Except that if you look at these groups, you can see that the names are exactly the same. O2 is dioxygen, N2 is dinitrogen and NH2, CH2, CH2, NH2 is the name of ethylene diamine. Also named ethane 1, 2, diamine, correct? Now what do we do when we have more than one type of ligand? In that case, alphabetical order takes precedence. For example, in this coordination complex which is CR, NH3, CH2, CH3 plus, so here the name of ammonia would be amine and water would be aqua, right? So which one takes precedence alphabetically? So based on alphabetical order, we would prioritize amine over aqua. Now when we have many ligands of the same type, we use prefixes like dye, tri, tetra and so on. For example, if we have a complex like CR, NH3, thrice, H2O, thrice, 3 plus, then the naming of the ligands would be tri, amine because we have three ammonia groups and tri, aqua because we have three water molecules. Now as I mentioned before, amine takes precedence over water alphabetically. So the naming of the ligand would be tri, amine, tri aqua, chromium, chloride. Because as I said before, inside a coordination entity, we will first name the ligands and then we will name the central metal atom, right? And we will get to that later how the entire naming is done. But for now, understand that when we have monodentate ligands and when we have multiple of them, we first have to look at the alphabetical precedence and then we need to prefix dye, tri depending on the number of ligands that we have. Now remember, alphabetical precedence is for the ligands. We are not considering it after we use a prefix. Now when we have polydentate ligands, instead of dye, tri and tetra, we have a slightly different nomenclature, which is bis, tris and tetrakis. Bis for 2, tris for 3 and tetrakis is for 4. Now this becomes important when we have complexes where we have both polydentate as well as monodentate ligands. For example, in this particular coordination complex, we have a monodentate ligand as well as a polydentate ligand. So in order to avoid any confusion regarding the naming of these ligands, we actually keep them very distinct. For example, here we have dichlorido that corresponds to 2 chloride ligands and bis ethane-1-2-diamine which corresponds to 2 molecules of ethylene-diamine, which has been a polydentate ligand. So remember, this is purely to make it clearer or to avoid any kind of confusion between the naming of polydentate and monodentate ligands. So the naming of this particular complex would be dichlorido bis ethane-1-2-diamine which is the name of the ligand that we have followed by the name of the central metal ion. Now here we don't have any anionic group so we end the naming with the metal ion. Now another thing that we need to remember or keep in mind is that when we have polyatomic ligands like ammonia or water, we usually enclose them in brackets like this. For example, in this particular complex we enclose a polyatomic ligand ammonia within brackets but not chloride group. So this is again a small distinction that we need to keep in mind, okay? So that's pretty much about how to do the naming of ligands. Let's now look at the naming of central atom, right? After ligands comes the central atom. In the case of central atom we always need to write it along with this oxidation number. For example, when we have a neutral or cationic complex like this, the name of this particular complex would be triamine triaqua that which refer to the two different ligands chromium-3. We all know how to find the oxidation number of chromium here, right? Suppose x is the oxidation state of chromium then we have 0 and 0 because these are neutral ligands and then we have 3 chloride ions here and the overall charge is 0. So this would give x as plus 3. So here remember the central metal is always written along with the oxidation state. So this is when we have neutral or cationic complex. What about anionic complex? Suppose you have an anionic complex like K4, Fe, CN6. So this has the charge Fe, CN6, 4 minus, right? When we have anionic complexes the name of the central metal will end with 8. Okay, so let's try naming this coordination compound. So what was the first thing that we saw? The first thing is to write the name of the cation. And if you break up this coordination compound we know that this is the cationic part and this is the anionic part, right? So the name would be first potassium that refers to the cationic part. Now we need to focus on the anionic part which is our coordination entity. So within the coordination entity we said that first we have to name the ligands and then we have to name the central metal atom, right? Now here we have 6 synogrope and when we have anionic ligands the name ends with O, correct? So that would be potassium hexasino, hexasino would refer to 6 synogropes. And now that the ligands are over we have to look at the central metal ion. So the name of the central metal atom should end with an 8 because it is an anionic complex. So here it would be potassium hexasino ferrate and what is the oxidation state? 2. I am going to let you calculate that, okay? So the name of this particular complex is potassium hexasino ferrate 2. Now a small thing that you need to remember is that we don't put any space between the ligand and the metal atom, okay? Hexasino ferrate is almost like a single word. We have space only between the cationic and the anionic part, okay? So before we wrap up this video let's quickly look at one more example, alright? Okay so let's try to name this particular coordination compound. So first we have to name the cationic part, correct? The cationic part here is nothing but potassium and this is the anionic part, right? So the name here would begin with potassium. Now what we have here is an anionic complex. We saw that within any coordination entity we first have to name the ligand and then the central metal. Now if we have a negatively charged ligand then it would end with O and if it is a neutral or cationic ligand the name almost always remains same except in the case of few ligands like aqua for water, amine for ammonia and so on. So what is the ligand that we have here? OH group which as we know is a negatively charged group and how many such groups are there? We have four groups. So that means the name of the ligand here would be tetrahydroxyl, alright? So the ligands are sorted and now we need to move on to the metal. In an anionic complex we just saw that the name of the central metal atom would end with an 8. So here the metal is zinc and that means it should end with zincate. Okay, no space here, alright? No space here. And what is the oxidation state of zinc in this? We have 2 plus x plus 4 into minus 1 is equal to 0. So x is 2, okay? So the oxidation state is zinc 2. So the final name of this particular compound would be potassium, tetrahydroxyl, zincate 2. Remember no space between the metal atom and the ligand names, okay? So let's practice naming a few more compounds in the next video.


And welcome to At the Crossroads. I am your host, Keisha King. It's so good to be with you today to share with these Pacific resiliency fellows. They're here to tell us about their second cohort and what we have planned for this year and the coming years right here in Hawaii and all throughout the Pacific. Let's welcome our guests today. I'll have them introduce themselves. We have a lot of people here today. My name is Aliyah Herman. Thank you so much for having us here today. I am the program manager, so I've been developing and overseeing the Pacific Resiliency Fellows and I work for KUPU, who is the organization that is running the program. Wonderful, Aliyah. So glad you're here. And hello, Aliyah and Ali. My name is Blodak. I come from Palau and I'm a participant in the Pacific Resiliency Fellowship. That's amazing. Thank you both so much for being here and we have two more guests waiting in the wings who we will speak with right after we talk with you guys after our break. So, Aliyah, please tell us what exactly is the Pacific Resiliency Fellows? So, the Pacific Resiliency Fellows program was launched out of the World Conservation Congress that happened here in 2016. When that Congress came we said, how can this mean more for Hawaii than just 10 days? And so the idea was for KUPU with our mission of working with youth and young professionals to learn, serve and restore was maybe we could do something bigger than Hawaii, do something in the Pacific. So, we developed this fellowship program as a way to support resilient communities. So, how can we help communities across the Pacific become more resilient? What resilient? What kind of skills do they need? What kind of tools can we provide? Okay. So, you asked good questions about what can we do to help. Right. But what exactly are you helping? Sure. So, the programs, the program targets rising professionals who work in conservation and sustainability. We have fellows in Hawaii, but also across the Pacific in Palau, in Rapa Nui, one of our guests today in the Northern Mariana Islands in Guam, in American Selma. So, we have all of these different island communities that are facing these different struggles. And one of the things that we heard again and again is capacity. That we don't, there's not a lot of capacity to support, especially people who are there and deeply invested. So, one of our first goals of the program was to build local capacity. Then from there we said, you know, what else is needed? And the other thing, there are a couple of other things that came up. The other is to build a network. So, how can all of these communities, all of these people working in these communities facing different challenges, but also the same. You know, they have a lot of shared, how can they be learned from each other? How can they feel supported by each other? That was the second goal. How can we build a network? And the third goal is, you know, we want to not make this more about just let's help these individuals. Like, I want Blodok to do well. Obviously, I want him to be better at what he does. But we want to impact his community as well. So, I sort of see them as ambassadors to their community. They're coming here and we want them to be able to bring back. So, not only all these professional development skills and trainings, but also we've been working to help amplify their real time on the ground work right now. So, they bring a project through the program and that's one of the other key pieces. How can we make them more effective right now in what they're doing, as well as over the long term? So, for those who are not familiar with Coupu, can you tell us about that? Sure. Coupu is a non-profit based here in Honolulu that was founded in 2007 with, you know, our tagline is learn, serve, restore. So, really, it's creating a variety of different youth programs, fellowship programs, young programs for young professionals where they are, and actually the fellowship program is a little bit different than a lot of what we do, but where they are working sort of in the field in many cases, you know, learning how to work in conservation, but also getting a lot of those other sort of leadership skills, professional and personal development skills as well. Okay. So, you shared with us what the program seeks to accomplish, and you've explained Coupu a little bit more. So, in this first cohort, how many fellows participated in the program? So, we have 13 fellows, and as I mentioned, they're from across the Pacific, and they come, so it's set up as a 16-month program. So, they come here for 10 days, and then they go away for a year where they're implementing their project work, and also continuing to support each other. They're doing peer-to-peer work. I'm continuing to support them, and then now they've returned for their second session. So, this is another 10-day session sort of to bookend it, and then they will have their hoike, or their graduation on Tuesday. But what we're hoping is that that's not the end, but it's just the beginning of what will be sort of ongoing kind of network and support amongst them, and that we can continue to find ways to support them beyond the program. Okay. So, again, you've had some fellows who participated in the program. This isn't your first cohort. It is our first cohort. This is our second session of our first cohort. This is the pilot. So, we talk about them as the hyapo. They're the first ones. So, they have really they've been our guinea pigs, and they've been really awesome about it. And so, yeah, we've really been trying to figure out what works and what doesn't, and how to make this meaningful so that we can hopefully replicate. Because the real goal is if you can have cohort after cohort, then you have a broad network that has shared skills, hopefully some shared values, and then maybe eventually they can make a real collective impact on a broader, more global level. That's the goal. And I'm so excited about that. I'm excited that this is your inaugural group, your inaugural cohort, and the hope that annually, I suppose, you will do this. Every two years. Every two. Because it's just a six from sort of recruitment to both sessions. So, the goal is to be able to run a cohort every two years. But, because it's such a new program, we are still trying to raise funds to figure out a way to continue the program. And so, we hope that people can see the impact that it's making, again, both on these amazing individuals who I've been really lucky to get to spend this time with, and also more broadly, and that we can find people who are really willing to invest in the program over the long term. Because it's not one of those things where you're okay, we got rid of 100 acres of invasive bamboo or whatever it is. It's something that you have to invest in to see the results. And so, that can make it sometimes challenging to find the right fit for funders, but we're really hoping people will start to see the impact. And that when they, especially get to spend time with these guys, they see their heart, their passion, their talent, and that they want to help us give them more support and give more fellows support in the future. So, now, for this cohort, describe the application process to us. What was it like for them to get involved? Oh, well, we did a, again, a lot of networking to try to make sure that this opportunity was available for folks, you know, in all these different communities. Bloda can tell you, he comes from a community of 60 people. So, when you think about, you know, how do you reach that one like him? Yes. And then, you know, they went through an application process that had essay questions about, you know, their work, their commitment. One of the main things we looked for was commitment to place. But all of these fellows, you know, it's not a requirement, but all these fellows were born and raised in this place. And a large percentage of them are also indigenous. So, these are people who are deeply committed to these places over the long term. They're not two-year transplants who just want to go travel around. So, that was one of the key things, their passion, their commitment, their experience. We were looking for people who could bring something to the table because that they'd already, it already worked. So, this is what we're saying. We're saying rising professionals, people who've had some experience and who we see going further. And then we interviewed, we had interviews as well and made our selection, which has been, we are very pleased. Very, very good. I am super excited for that. So, Blodak, are you ready for me to ask you questions? Yay! Tell us why and why was it important for you to take part in this program? Well, as Elio was mentioning, I come from a very small island of Kayango and our community has found its way that we're losing people. So, I'm here and I want to plan a seed in a way at our island to make sure that it can reap benefits for the people of Kayango. And I think this training and opportunity has given me a chance to develop my skills and put some more tools in my toolbox in order to attack some of the things that we're facing, challenges. Wonderful. So, really, 60 people in your community, that is very different than what we're used to hearing about. Yeah. So, it went from the 1940s, it was about 2,000 people, but because there's been a lack of opportunity on the island, everybody's kind of been setting out to seek more opportunities. So, I think, to me, it's about finding a way to bring back the people. And is that your ultimate goal? Find a way to bring them back? Yes. I mean, that is the ultimate goal to bring back a lot more people home. That way we can provide better as a community for our environment and whatever is around us. This might be too much of a personal question, but what made you stay? If everyone else is leaving, what made you stay? Well, home is where the heart is, and my heart lies in Kayangan. I've had the opportunity to visit many places, including Hawaii, to kind of deepen my understanding and also load my commitment to Kayangan because at the end of the day, it's home, and that's where I would love to spend the rest of my life. That's so beautiful. I can see why he was chosen. And he's such a great example of what it means to try to build a resilient community because so he's working in conservation. He is managing the projected area around there, but so much of his focus, yes, it's about restoring the natural resources there, but it's also, like he said, restoring the people. And so he's doing things that you might not think would come like fighting for higher wages for the staff that he has, so that they can stay. There's so many pieces of what it means to build a resilient community that extend beyond the job description of help bring back the coral and the trees. And so I think he's just such an incredible example of that holistic approach that needs to be taken. That's amazing. And thank you so much for your commitment and hard work and dedication. We know that it is making a difference. Do you care to share any successes that you may have had already? Well, I've been, we were able to renovate one of our boats, which has helped us do our job more efficiently in a way because we have two marine protected areas that we have to do surveillance around because nowadays everybody's trying to get their share of the fish. So we have two marine protected areas that we are now able to conduct surveillance effectively. Wonderful. And you were a part of making that possible. Yes. I bet. He seems like he's being modest. Yeah. I think that's a fair assessment. Well, thank you. That makes a huge difference for everyone involved. If that is a food source and just everything else. Yeah, it's gonna make a huge difference. And you're fighting for higher wages as well. Yes. Yeah. I think I really want to raise the standards. It's really hard to raise the standard without raising the wages. And I felt like that's kind of one of the main reasons why a lot of our Rangers just came to work and then left after a year of training to join something better. So that you all provided the training and then yes, so we would pay for the training and then we take it and go to the national government level. I see. Yeah, that's not what we want. No, we want you to get trained here and then to stay here. Is that right? Yes. Yeah. Okay. So hopefully this next go round, they will do that. Yeah. Good for you that you're doing and that you chose to stay. I know it's going to make a huge difference in the lives of the families that are still there. So thank you for your heart to serve in such a way. And thank you to Aliyah for what you've done as the managing manager, project manager. Senior program manager, whatever person who steers them in all different directions and says, Hey, do your work and come together. Oh, man, with her emails, it's it's it's inspiring to have her to keep on coming because of course, after a year, trying to reach out to us was a bit of trouble for her. But I really applaud her for keeping keeping us tied together. So we're able to come back together. Because this has been actually a very inspiring group of people that we've worked with and it helps me push my goals further. Yes. Because when you're around people that are helping you toward your goals and also working toward their goals, it makes you want to work a little bit harder, right? You feel accomplished and feel good about that. So I feel good to sit next to you guys. This has been good. So we're going to take a quick break. And when we come back, we're going to speak with two other fellows and who are also here a part of the program from other places. You guys are going to be waiting in the wings while we listen to their stories about how they got involved and what they hope to achieve as well. Thank you so much for being with us today. Thank you so much for taking the time to hear our story. Yes, indeed. And we're still looking for more funding. Is that right? That is right. That is right. Yeah, first cohort number two. That's right. We want to get another group through and build our network so we can make real change. Awesome. I think that's a good way to end it with you guys. You guys have been perfect for this segment. You've been watching At the Crossroads and I'm your host, Keisha King. We are speaking with the Pacific Resiliency Fellows and we will be right back after this quick break. Aloha. This is Winston Welch. I am your host of Out and About where every other week, Mondays at three, we explore a variety of topics in our city, state, nation, and world, and events, organizations, the people that fuel them. It's a really interesting show. We welcome you to tune in and we welcome your suggestions for shows. You got a lot of them out there and we have an awesome studio here where we can get your ideas out as well. So I look forward to you tuning in every other week where we've got some great guests and great topics. You're going to learn a lot. You're going to come away inspired like I do. So I'll see you every other week here at three o'clock on Monday afternoon. Aloha. Hey, Aloha. My name is Andrew Lanning. I'm the host of Security Matters Hawaii airing every Wednesday here on Think Tech Hawaii live from the studios. I'll bring you guests. I'll bring you information about the things in security that matter to keeping you safe, your co-workers safe, your family safe, to keep our community safe. We want to teach you about those things in our industry that may be a little outside of your experience. So please join me because security matters. Aloha. Aloha. My name is Chip Fletcher. I'm at the University of Hawaii School of Ocean and Earth Science and Technology. I'm here to tell you about the four key things you can do to combat climate change. Have smaller families, eat a more plant-based diet, drive less, and fly airplanes less. Thank you very much for your time. Aloha, and welcome back to At the Crossroads. I'm your host, Keisha King, and today we have guests with us from Pacific Resiliency Fellows program. And so right now we have with us, Mana and Tiare. So glad you guys are here to join us today. Thanks for having us. Thank you for the invitation. Yes, indeed. Thank you so much. We're happy to have you and find out more about this program, what all got you involved and interested in doing this, where you're from and all that good stuff too. Okay, so we will start with, you want to do it ladies first? We'll start with Tiare. Tell us where are you from? I'm from Rapa Nui. I'm a lawyer and I'm working in an action plan for climate change. Wonderful. So now with all of that being said, what made you get involved with this program? First of all, I feel like it's a privilege and it's a dream that comes true to have this network around the Pacific. I feel the responsibility too. I'm part of a small community in Rapa Nui where 7,500 inhabitants. So for me, I think the most important thing is to see a broad picture, is to see things from outside and to have different opinions, different perspectives. We are facing similar problems. We are at the same time, we have a lot of differences, but we are part of the Pacific and we are part of the world.  So it's very nice to be here. Wonderful. So you feel that as though being a part of this program is a privilege. Tell us, what are some of the highlights from the program that you have taken away with? So many. I learned a lot and I share a lot too. So the first year it was very interesting. The system, we have the opportunity to visit amazing places. What were some of the places? In this, we start with Hokulea. So imagine that. So I just say that. We are so privileged to have, we went to Kalatu, we visit and we helped constructing these fish ponds last year. We are working with the community. We are working with students too. I don't know, so many things at the same time that you need. I'm pretty sure that we need time to just digest all this information or this knowledge and we will apply all this stuff eventually and now. So I feel more confident. I have more tools to help my community and to be part of these small changes. So we need to start in the local level to see the change in this generation. So I'm very glad that I'm part of that. So thanks for the invitation. I feel just gratitude. Wonderful. I love that. She says, I feel gratitude for the opportunity to serve because this is about work and a lot of hard work. Is that right? So what is the first initiative that you're going to work on when you return back home? I'm working in this action plan. The plan consists in adaptation and mitigation at the same time because it's a small island. So I'm more confident right now especially to work with my community to be a leader. I'm more flexible right now. So sharing with all these cultures, with all these islands gave me that. We are working in so many projects, so interesting issues at the same time related to culture, related to how to protect the environment, climate change, how to protect reef, marine protected areas. So so many information. So I just need time and just continue to, it's very, sometimes you feel so frustrated with these issues. So sometimes you just, I don't know, it's difficult to continue. Yeah. And having all these tools, meeting all these people, see what's going on in Hawaii for example, in terms of technology, in terms of confidence. So many different things. I'm sure when you put it all together it makes a huge impact on you. As you mentioned, your confidence, you're prepared now to go back. But you probably have to have some time to like take it all in. So Mano, we're going to jump into you as well and say where are you from? I am from Waimea, Hawaii, Maryland. I know work for Lili Uokalani Trust as their natural resources manager. Wonderful. So you're already involved. But tell us, what are some of the focal points that this fellowship has caused you to take a look at? A lot of things. I think first and foremost for me is the relationship component. Meeting people like Tiare and Blodok from different areas around the Pacific has really been special. But understanding that everybody's looking at problems from a different lens from their specific cultures is inspiring. And it's really been impactful in my life to know that. I have folks in Palau, I have folks in Napa Nui that I can call to for all kinds of problems and work together on it. That's amazing. So now in your community, both of you have a bit of a larger community than the previous guests, Blodok, that we learned. He has about 60 in his community. You said 7,500. And how about you? So I live in Waimea where I think our population is around 5,000. Okay. But I work in a community a little bit further away, about an hour away in Kona. I'm not sure what the population is, but it's far greater. It's the second largest community on the island. Yes. Okay, wonderful. And so you have a lot of initiatives that I'm sure you're going to jump on when you go back, but tell us what has this done for you personally? What has the impact of this fellowship had on you as an individual in addition to the satisfaction of the relationships professionally? What has it done for you? Well, there's a lot of tools that we learned. Like today, for example, we learned about discs. It gives you a better understanding of your characteristics and your behaviors and how understanding those behaviors will really help you as a leader and working with team teammates and trying to resolve issues, but also in community meetings and whatnot. So there's several tools that I've used from the previous session that we got together. And I don't know. I keep going back to the relationships piece. That's really what hit me hardest. That's fair enough. That's good. Relationships are important. Everything is built upon relationships and having good relationships. And take time. And it does take time to build them. And trust. Yeah. I think we, the first year was amazing, but this this second year is yeah. Yeah, we've gone, we've gone to a couple different areas too. And it's kind of opened up, I think opened our eyes to you through this experience of the types of economic development that we could bring back to our places. Like Godak was saying, bringing back jobs, but just jobs, but jobs that are sustainable and for the environment, jobs that are we're taking care of, whether it be land or people or children. Rather than creating jobs of creating material things of consumption. So really flipping that over and what are, what are the future jobs for our kids that's going to really benefit our community and the world? Don't tell us. What would you then say to someone who is considering getting into this program? What is something that you would say to them, tell them and make sure you speak loud and clear so they can hear you. And if you want to, you can look right at that camera and let them know. Either. Well, I would like to say it first. You know, when I first started coming into this, I looked at it more personally and what can I get out of it. But after being in this experience and experiencing other people and the challenges that they're facing, it really put things into perspective for me and made me look more holistically on problems and issues and how we can really get together to solve all these problems. And like you said, with the Hokulea was a special experience for me. We got to go on a sale and I know I said one thing that was interesting that we need to network as people. You look at the mission of the Hokulea and traveling around the world and he said we need to get this network of people around the world but not geographically separating them but networking communities together. I love that. It's a big takeaway for me and that's how I receive these relationships. Yeah, speak loud and clear and let us know what would you say to someone who is considering entering the program? I was talking with a fellow a couple of days ago and I said that now I think that I start to understand more the word Kuleana. I like this word because that means a lot that I think if I can describe this program I will use that word Kuleana. It's a responsibility not just with your community, it's also without us and without the wall. Just doing a small thing put a seed in your place and like that. Yes, plant the seed, start where you are and work to make a difference right where you are. I think that pretty much sums up what you guys are saying. Am I right? Yeah. Yeah, build those relationships. So now do you have any idea of someone back home in your communities that you would already recommend for this program? Oh yeah. Yeah, I do. Yeah. Okay, we're hoping that you guys go back, mention this program that you've been in and what have they said? Has anyone noticed a difference in you all that you've been involved? I'm curious. I don't know. I mean, I don't know. I hadn't talked to anybody specifically about it, but I think so. Yeah, I don't know if you have any. Every time, at least in last year when I finished with the first of this journey, I did some interviews in the radio and in the TV programs in Rapa Nui, so that inspires a lot and we had a lot of calls and a lot of people start to ask me about this program, so they start to be more, I don't know, involved in my process. So and now they know that I'm finished the second year, so they're supporting me too. Yeah, I think support is the biggest piece. And that is. And that is. And so we want to thank you all for what you do. We want to thank you all for joining us as we've been here with Pacific Resiliency Fellows and some of the fellows who've been involved with the program, they've been through this for two years now and they will be graduating July 9th, 2019. The mayor and I'm sorry, the governor, Governor E. G. and First Lady will be there. Thank you for watching at the Crossroads and we'll see you next time. Aloha.