 Good morning. I'm going to give this talk. I'm from Peru. Welcome to this is the right session if you're kind of lost. Welcome to my talk. This screen, I'm trying to just basically say that sometimes I get this when I access the Drupal org site from my country. But I think everyone here is really awesome, rocks. So I do appreciate for coming here. I think everyone of us here is very important. And I can imagine like 5,000, 4,000 being in this conference. So it's great to be here. Cordo Val, Luis for the tsunami. That's my nickname. And I do some development. And I work for Underground Elephant and do other consulting as well. All right, so let me get your attention. So I'm here to help you solve problems in terms of how you are going to upgrade Drupal or other software and make it portable. So let's start with some numbers. This is a slide from a friend of mine, Jacob Salas in UK. So he is here presenting some numbers, dependencies. So packages, for those who do not know, is a repository for worldwide created packages in PHP. So most packages or all of them should probably have a place here. And this shows basically the dependencies that these packages have. So some packages are totally standalone. And they are the great majority. So that's the trend. Some depend on symphony, others on send, other packages. But the trend is that we create packages that are pretty much standalone and well-decoupled. That means they don't have other dependencies. This is another graph from Jacob. He's showing here the dependencies of the symphony packages. Those are listed on the bottom. And of course, the most popular one is the YAML component. And so he's showing how many other packages depend on this popular component. And I like to say that the greatest degree height, the better, because that means other packages, other than bundles, bundles are specific packages related to symphony in the symphony ecosystem. But more packages that are not bundles depend on YAML or depend on other components. So seeing a lot of green here is a good trend. So what I'm trying to say, basically, is packages need to be standalone. Packages need to have less and less dependencies. And if they do, they should have dependencies of very well-known packages. This is another graph. This is mine. I basically did a search on using PHP for the usage of symphony classes in Drupal Core. So this kind of shows that Drupal is actually very well-sold in symphony usage. And among them, you cannot see it, but there is the event subscribers. There are routing, a lot of usage there. So those are the main two peaks. There are others, but pretty much it's not really about the quantity. It's about the quality. So let's just assert that Drupal is actually using probably the most important components in symphony. Now, what's the whole point of this talk? It's about avoiding certain situations when, for instance, if you're a big company and release an API, in this case, an API that you can access over HTTP requests and stuff. And then you break it. Then you have to post these kind of notices. That means you are not going to longer support some functionality and you're going to release new stuff, but you're breaking stuff. And you're making your users write new software or make new changes to keep up with your advancements, which is good. But at the same time, it's not the best. Maybe there is a better way, a better transition. So symphony has a release cycle. The yellow bars show a time span for four months. And the dot blue is two months. So you can see across the years, we're releasing version 2.2, 2.4, 2.5, and so on. The green stuff is the support cycle. So that means we're going to add bug fixes, new features. But usually the new features, especially, they come into the next version. And the reason why, I guess I'm putting this backwards. So in order to actually have an orderly release cycle and an orderly process of not making our users break their software or whatever they build on top of it, symphony released a backward compatibility promise document, which basically tries to address these problems for people that use symphony. And in this case, Drupal is a big user of symphony. And let's talk about semantic versioning. So the word semantic comes from the Greek semanticos. And that word basically means it means something. So it means it has some meaning inherent to it or attached to it. When you see numbers like this for your versions, so suppose, OK, Drupal 8.x, what does that mean? So the 8 means something. The x means something else. And so what it means basically, and this is happening with most or we want that to happen for the whole entire PHP ecosystem of packages. And that's a feature, by the way, components and packages. So we want this to happen for all of the packages. So if you are going to release your package to the public ecosystem or you're planning on releasing a software that other people would use, think about this, because those numbers have meaning and they should mean something very concrete. In this case, the first number means the major version. So Drupal's major version is 8. For those who were in version 7, it's a great change. It's a major version. The 2 means here that it's going to include new functionality, but it's not going to break the API. So going from 7 to 8, yes, we break everything. We've broken APIs. We've broken many things. People need to really upgrade and mine these changes. So if it's a minor, so let's say 8.0 to 8.1 or so forth. That means you're adding functionality, but you're not breaking the API. You're respecting the API. And the patch last number is really just a way to say, hey, you can upgrade safely. Just include some backfixes here and there. Let's talk about symphony repository in particular. So you go to GitHub, symphony, symphony. You click on the release tags, and this is what you see. You basically, if we actually are taking care of, say, we are building Drupal, Drupal is using 2.4.1 at this point. And yeah, we're planning on using the latest symphony, maybe, or upgrading. So suppose Drupal was using 2.4.4, and we're going to upgrade to 2.4.5. This is what we should be interested in. So symphony has a documentation for these changes, and this is done via change logs. So if we're interested in 2.4.4, that means we need to take a look at a change log 2.4. And that's going to tell us exactly what backfixes are included to it. So we're going from 4 and 5, and we talk about that before. That's the minor number, or sorry, the backfix number. That means we're including some backfixes, as you can see in the lower screen on your right. It's not important right now. The mechanism is what is important. Let's take a component within symphony. Suppose the class loader. And we know that Drupal is using this, because he needs to auto load some classes to use them around. And we click inside the component class loader folder, and we find this change log also. But this is probably a lack of documentation, or maybe because symphony does subtree splits. That means it gathers all of the components into one single repository. And so we want to see here, because a lot of people is using more and more independent components, not symphony, but just the components in example Drupal. And we want to see here really a detailed backfix list for this particular case. So if we move from 2.3.0 to 2.4.0, that means we want to see backfixes and API additions, not breaks, not bcs. Sometimes they put bcs to stand for backward compatibility break. That means that they have really broken the API, and they need to be going to 2.5 or from 2.3 to 2.4. But there is a way that you can keep track, even though it's not documented. If you click on the history, and then only for that folder, then you'll see exactly what has been done. So as you can see on that detail, it's not critical, but you can see basically that Fabian has merged some branches from 2.3.0 to include some backfixes and such. And this is basically record. Every commit gets recorded, and we can see it there. So in case that it's not documented, and I want to upgrade the class loader component, and I want to include some backfix that I really need, because I'm releasing the next version of Drupal 8.2 or something, then this is going to be where I need to go. So can we please raise our hands? Who knows Composer? OK, most of us. Drupal uses Composer, and sometimes I see dependencies in some projects. They use a lot of stars and stuff, and there is a use case for that. But sometimes, because we're talking about semantic versioning and it means something, we don't want to actually always use the star in the case that we actually are tracking all our dependencies correctly or very tightly. But we want is to convey meaning. So I suggest we use curly. Curly is like a tilde operator, which means basically that it's going to tell Composer use 2.4.1, in this case, or the most significant lower number. So that means that it can pick up 2.4.6 or such, in this case. So it's not going to download for you under your vendors folder the 2.4.1, but it's going to download 2.4.6, OK? And so don't put 2.4 only and leave it up to nowhere, nothing. But you should put 2.4.1. That's the best practice, at least as my understanding from the documentation. And also in practice, I've tested this. So that's how it works. So in the overall thing, Composer.json is very important for tracking your dependencies. You want to actually have a very good understanding of what you're using from the basic components that you're using, whether that those be symphony or whether those be Aura2 framework components that are well-de-coupled or any other same framework, you name it. And Drupal is using a bunch of components and is probably going to be using more than 20 components in the future. And it's going to split the course, or we wish it could split further into components. So let's talk about dependencies. The problem that we're trying to save as we're trying to examine is how we keep track, how we don't break our software, how we upgrade freely. So dependencies is important. Why? Because when you have some dependencies on your packages, those could break too. And you want to tighten your versions as well, more specifically. So this package, for instance, the validator that Drupal uses has three dependencies, regular dependencies. And one of them is a translation, which is coupled. And the property access that is also coupled. You don't necessarily, well, in this case, you necessarily must have those components. Else, this doesn't work. And it's very popular. Now, the dependency injection has only one dependency. As you can see on the upper part, where it says one require dependencies on the left. But it has three development-type dependencies. That means that when you develop as a developer and when you're developing, you will actually download three more dependencies, which are config in the lower part, expression language, and yaml. So that means your package is actually coupled. But it's kind of like hidden. This is kind of hidden. Because there will be some classes that will use classes from these other dependencies and will couple your package. Or your package is not well-decoupled, that's what I'm trying to say. You can still use it without these other dependencies. But you will probably, at some point, want something better, maybe. Or you want to actually upstream and request, hey, let's decouple this. So in reality, it's pulling like four dependencies. Not just because the config component depends on the file system component as well. So you're actually thinking that you're pulling one, but you're pulling four more. Let's compare that or contrast this with the Aura SQL package, which is very independent. So it has zero dependence, so we're happy. And yeah, well, this is the version one. But the version two is coming up, I think, these days. So OK, we talk about packages. We talk about dependencies. We talk about versioning. We talked about the symphony release cycle, this problem. And there are ways we can address this. And this being, and I want to cite here a book from my friend Matthias Novak from Netherlands. So he's writing a book. It's already for sale, but the principles that he laid out and also another book from Paul Jones on modernizing legacy application, he's the author of Aura Framework as well. He has a team. I like this vision because it promotes the way that we're building the new era of packages and how we are going to release them, how are we going to maintain them, how are we going to avoid the people that depend on our packages to avoid for them to break their software. And so if you look at the core vendor folder of Drupal, you will see these folders. And in these folders, we don't see, for instance, the config component because Drupal has actually trimmed that even though Composer might also install it or the file system or expression language. We don't use them. So we trim it. So there are classes that have used statements with those classes from other components that don't exist. So if you use them, you'll break, well, you don't necessarily break your software. But in some cases, like the container builder or some other classes in Symphony, you'll have to be very careful what to use to avoid breaking stuff. So the goal or how we are addressing is we have to have two points of view. In a way, we want to, as package designers, look inwards. So inwards meaning our code in the package designer's land. And in the other, which would be outwards, that would mean package or looking outwards to the user side, user land. So in this case, we're talking about inwards. So the extension points from the standpoint view of the package itself. So pick up Jamel. Jamel is the most simple component you can pick the most popular. And it has only two methods, actually. It's very simple. So suppose you write a text file, and you put the extension Jamel, and you put this kind of food, like tacos, burritos, fajitas. And you're going to write a menu, sorry, a menu.php file. And in there, you're going to require, of course, your auto load from Composer. But you're going to basically parse it. So you take the Jamel. You call the static meta parse. You pass the name of the file that is on the same directory. And options is going to be a variable containing all those three types of foods. This is very simple. An array containing three elements and those type of foods inside. That's all you need to know really about how to use this package and how to, you know. Now Drupal uses this package to do configuration stuff. So all your services core definition stuff all goes in there with this type of parsing, Jamel parsing. So in Jamel, recently, like this week, someone actually wanted to put a feature inside. And they wanted to add this mapping to a standard class so that when they do, for instance, add like fajitas, comma, something like an object with curly braces and stuff, you would actually get a standard class object inside your variable options. So what to do for that? They added a new argument at the end. So instead of parsing having three arguments, the last one with the full values, they added a new one. So how does this, and this is the feature. So you have like an object and a standard class and inside also like another object. Actually this doesn't, yeah, it does correspond because the curly braces creates a new object, standard class. So this was a pull request and they have a diff in GitHub. So it got merged. And so they were actually changing only the inline class which is used by the Jamel class, which has the parsing method inside. So what they did is added a new argument, right? So why did this not break anything? Because it didn't have an interface. So the Jamel class doesn't have an interface. Maybe we should request one. It didn't, like it affected the signature of the signature is the, that's the signature. Like how many arguments, what arguments, what's their tap hint and stuff. It's not going to go into 2.6 because it's not a break. Or it's not a, well, sorry. It is going to go into 2.6 because it's an addition. So it doesn't break the API, but it actually is added functionality. It's not a backfix, so it's not going to go in 2.5.1. If you were extending the Jamel class and you actually added or overall that particular method, this would actually break your application. So let's unpack the implications of extending classes that don't have a clear interface and also the rules that Symphony or other packages create for us so that we can keep backwards compatibility. So there's a class which is extending a base domain and it's implementing a domain's interface. So it's got some methods and stuff. So let's look at a simpler example. So some class without extending and implementing is it has no contract, you can change anytime maybe. So we need, we're seeing that we need some rules of package design for this. Suppose it extends a base domain only, but then you add a new argument too and then the base, what do you do with the base domain? Do you add the argument, do you not? So that creates some questions that we need to resolve the same when you implement an interface. You have to, and you add a new argument, you have to do something about. So we're talking about now rules for package design. And Symphony has laid some rules. So if you actually take a look at a class or an interface and you don't see any tags or any doc blocks that say that it's an API class or an internal class or internal interface or anything and it's just like that, like for instance the JSON response class is like this I think and the Java class is like this. So it can grow, so be careful. That's the, you don't want to extend that. You wanna ask for an interface or wrap it up with the tools that I'm gonna speak later on. So suppose it has like an internal tag, doc block, that means that it's a non-public API. That's a private API for Symphony developers. You don't want to actually implement that class ever because it might break, okay? So it's gonna grow, can shrink, or worse. And it could be, I think it cannot be deleted, but still, like you wanna be very careful. Now if it's tagged with an API doc block, you actually want to rely on it, okay? Whether that is an interface or whether that is a class, you must focus on these type of classes, okay? So that means that this stuff is set on the stone and you want to actually do good things with it. Okay, so this is the example that I'm trying to explain. Suppose, and this is fine on the Drupal core. So they are extending IX response class from the JSON response. JSON response does not have an API, I believe, and it extends the response class which does have an API type. But the JSON itself, the JSON response class does not. So it could change or it could happen something. So extending that class maybe is not the best way. We could actually create an interface for us inside Drupal, extend that class, and then that'll be safer or easier to track. And we can add some tests and stuff and track it with tests. I'm gonna speak about that later. Another bulk sample, or if I'm mistaken, please correct me, there's time. And I'm not claiming here a total truth. But these I found in also in the core of Drupal. So they are actually extending the event class for adding methods and properties. And you can see here we have three methods and a protected property and three public methods. That means when if this event class changes, it's gonna break, or it might break. Let me put it that way. So maybe it's not, so maybe we need to approach this in a different way of creating an interface, pushing for some class that wraps these. Here's a good example. We're doing the container, we're extending the symphony container. We have added some override to the method. That means this get and sleep exist or do exist inside symphony container. So this is a good example why? Because we're overriding, but we're not extending the class in adding methods or properties. Okay, yeah, it's hard. You know, at some point you have to deal with it and understand this very clearly and just follow the rules, make sure like your software doesn't break, add tests, and here's how, or and then let's put an example. And Jamel Phile Loader is a class in Drupal core and it's also the name of our class in symphony. So we said that we Drupal was using Jamel and it had a dependency, a loose dependency on the config component, but we're not using the config component in Drupal, okay? The problem is that this Jamel Phile Loader class in symphony extends or has some dependency on the config component directly. We can not use it. That means if we use it, it's gonna break error. So how we, how it was dealt with, this is the, let's examine. So what I was saying, this is symphony class as you can see on the name space. You can see the red thing. That means PHP storm is detecting that those packages aren't in Drupal core and not even in vendors folder. So it's saying, you know, you're gonna run into problems. This Phile Loader in particular, that's going to be another class that depends on the base Phile Loader, which is alias to the Phile Loader, as you can see on line six, that is actually in the config component. That's pretty bad. I mean, for you, maybe it's not for symphony framework, but it's not safe to extend. So what Drupal did is basically they created their own Jamel Phile Loader. They simplified, but then in the way, we lose features. We wanna keep track of symphonies features, but we lost some features. We cannot, like, for instance, do imports. So we cannot import another file, Jamel file with some configuration in another folder elsewhere, or in the same folder even, and then import it. We cannot do that. It has to be like a float long file of Drupal services definition. So I talk about, so what I did is basically I saw this and I jump on Drupal org and I created a ticket. Actually, I wrote tests, or I moved tests from the symphony, Jam, Phile Jamel Loader into the Phile Jamel Loader of Drupal, the implementation, which is completely separate, but we want to keep track of the features. So there is a pull request, or like a div, I send there, to actually add some things that we were missing, because we are going to upgrade, remember, and we're gonna lose things that actually are added automatically, and because we did our own implementation, we didn't add. So a good way to get upstream benefits when you upgrade is to track features via tests. That means write tests, Drupal is still learning how to write tests. So I found this problem, so I wrote the test, so this is the TDD way, the test driven development way. You basically write the test first, you get two failures, and that means that you're lacking two features. And those features were exactly like the lazy type of service definition, and the other message that was actually improved in symphony for some tags, so the tags is a way you can tag service definitions, and those were different, so I just like did the change, make them ring, pass, and then send the pull request, or patch, or whatever. Another way that you could do outward now, we're talking outward, so the user line is creating your own interfaces, so Drupal needs to create their own interfaces, and so it creates a boundary that you can actually trust, so that you do the changes in one place, in one class, one implementation, or wrap it up, and we're gonna see an example of that, and then propose in-work, like upstream to symphony, hey, you know, you miss an interface here, and they say on the document, to do those things, to create issues on symphony, hey, please consider adding an API tag to this interface or class. So taking hours, this is what Drupal did. Drupal created their own Jamel class, and then we wrap, we're gonna wrap Jamel, which is a symphony name there, parse and dump methods, into our encode and decode methods. Pretty good, eh? And then we're gonna use all of these, the encode and decode everywhere in Drupal. So when there's an upstream change, then we just basically focus on one class, and that's about decoupling. Decoupling means when your customer, or whoever asked for Drupal a feature, and they need to change something, they change, they touch one class only, and not like the whole thing that we're doing now, maybe. Okay, so, yeah, and this is a joke, well, kind of joke, because I found this in Drupal Core. We're using like a type of registry, so the container, and we're passing it around like a static, and this is pretty bad. Anyone seen the movie Green Lantern? The parallax, those who are familiar, the ax of evil. So this is, as you can see here on line 38, so there's a comment, of course, let's fix this. And I hope that we can work hard to actually fix, get rid of this in Drupal 8.0, 8.1, if possible. But I understand that there was a need for that because we're migrating legacy code, and this happens. This is temporary, of course, I'm just mentioning it. Okay, so we are talking about respecting encapsulation, so when you turn properties, there were some poor requests from Drupal LAN to Symphony. They were saying, oh, please, make these properties public. And we're custom in Drupal to do that, and Symphony by default sets their properties on their classes to private. The ones that are not, because we're talking about encapsulation. We have one class to do, one thing is a single responsibility approach. And if we turn those things public, then we break encapsulation. It's like, you know, people, it's like they'll take anything from you. And so we respect APIs, also we respect our code, and there's a way that you use deprecation. So in Symphony, sometimes in order before to jump to the next version, like major version, you want to maybe use deprecation. That means you can have like the same things doing, like two things doing the same, but this one does it better, but this is deprecated. So you'll kind of help your users transition, that you could still have that functionality. Your code is not gonna break, but hey, there's this new thing that is better. And here I'm gonna stop a little bit to talk about the work in Drupal that some amazing people is doing. And I like this because this comes from some, maybe it's around, but yeah, there it is. So he's done like a work on aesthetic life for a year or some more actually. And this is a defect I took from his work. You can check it out. It's basically about addressing the assets problem in Drupal and it's very interesting. And his approach basically involves the creation of some dependencies, some libraries. So he separate graphs to take a look at the problem and basically say, okay, this could be taken into a library. This other could be taken into another library because some other people might use it and might help improve Drupal core or Drupal packages or the ones that, the packages that it uses. So in this case, he's created like two libraries. In this case, Glyph, as you can see online, seven and eight, frozen. And they address particularly with like the ordering of graphs, Glyph, that's Glyph. And then frozen, which basically wants to address the problem of when you want to create an object that you can freeze and lock. So and how this is used, just take a look at the code and you will see that those requirements are the functionality that Drupal was needing for maybe ordering their libraries, the assets and stuff. So it's pretty interesting and see how this is evolving. This is frozen, basically if you have a counterclass, you can freeze it, it's not frozen, you increment it, it does increment from zero to one, then you freeze it and then you try to increment it and then you get an exception. All right, so we're getting close. So this is the whole point. I mean, we're taming wild code and I include symphony code here also, not just Drupal. We're taming wild code because those, it's like balls, they have horns and you have to really want to have control of these things. It's nice code, it's code that does a lot of stuff. Like I love Drupal because it's very practical, like it does stuff, it gets the stuff done and but we have to tame it and same with symphony. So that's a new, and I wanna see maybe Drupal evolving into components, who knows, you name it. And for more information of my view, my point of view on Drupal, I've taken a look at the core a little bit. I've written seven blog posts just these past two weeks. So you can check it out and CraftedOnline.com for more details specific that is there out of the scope of this talk in particular. I also want to wrap up here the problem of versioning and semantic versioning and that we must know to handle Drupal. I was participating also on the sprints and some people were asking about Composer and Behad and the Twig and certain stuff that really, I suggested let's a couple, let's a couple and I really love the community for doing those sprints. I wish symphony could do more of those sprints but it's great, like you have a great community. I am very glad to be part of this community. So and I wanna recommend two projects. One of them is from my friend Aaron. He's worked on Builder. Ever, raise your hand if you ever wanted to actually have the functionality of FIM or ANT, you know those automatic builders, but in PHP. Nobody, I do. So this is great, this project I'm using everywhere. I work in open source, Gash uses it and let's take a look at Gash. So you ever wanted like for contributing, you ever wanted to be really placing fast at contributing and maintaining as maintainer of a repository of packages. Then take a look at Gash. I really encourage you to do that. Gash is a project I started maybe a year, something ago, maybe two years and it has very like top level intervention from these guys, the stock Sebastian and Dan Leach from UK. So it's really amazing how the architecture has evolved and I really fully recommend, I'm using it at work and I look like a beast because the pull request like five pull requesting one hour or something like that. So I fully recommend, it works with all the other, like the, you name it, GitHub, GitLab, Bitbucket, GitHub Enterprise, we're gonna make it work with Jira and actually close to that already. It's already possible and we're gonna make it work with Trello, what you name it. So I fully advise you to do that and I'm actually taking also, is Alex bought here? No, okay. He's a top developer in Drupal and he has a patch to utilities, a repo in GitHub that he uses for taking a look at the patches on Drupal.org and I took that and I'm cleaning it up and I'm thinking that's a good addition for the Drupal family. So it might turn into an adapter. So you can actually, from the command line, actually send patches to Drupal. That'll be cool from the command line. So you don't have to click, click, click, click, click, click and get your elbows fallen. So, but you'll do that because like for people that do this many times a day, like leave there, you want to have this. So trust me. Thank you, well, my parents and thank you, Keith, if you're around and down to the Drupal Association for bringing me here, helping me get here and my friends, Keith and all people in the place I work at Underground Elephant. So this is the link for polling, the poll that I created. So if you like this talk or hate it or hate me, you can go in there and click and it's live actually. So you'll see it real, really. So that's it and with that, maybe I'll take some questions if there is any.