 Good morning. Good morning. Good morning. Is it okay? Yeah. So we have like a minute more, about a minute, a minute longer, so I'm going to take that minute. Before I start, there is a talk in the Upper Room Digest Shop. It's a talk I intended to go to. So if you're interested, this would be a good time to switch. If you go there and tell Mark you're representing me also. Didn't convince anyone? Right. So I'm going to give a talk and set it on, it's called TifffuckingToty, it's about this practice. And I didn't have time to submit it properly because I was told about it about 15 minutes ago. So the idea is that we have a lot of things that we do, a lot of technologies that we use and I wanted to make a list of recommended ones. Which one to favor over the other? And this is a talk I gave at Kluge PM in Romania a little while ago. Please do come in. Do come in. Faster. Faster. Alright. So, of course we all love parole. That's why we're here. It's fantastic. It's a great language. We enjoy it. We enjoy the community we build around it. It's our jobs. It's our toys. It's our fun and games and all the stuff that we do. And we really, really, really like TifffuckingToty, which is our slogan if there's more than what we do. Because with TifffuckingToty, basically we promote the idea of having multiple solutions to a single problem. And this is really good because different solutions provide different benefits. And this is, I think parole is one of the few languages that actually really promotes and is very proud of the idea of having more than one way to solve a problem. We really like that concept. We promote that concept heavily. And it's fantastic. We absolutely love it. But not always. And you probably know what I mean. See, sometimes when we have too many solutions to a given problem, having so many can lead to anger, frustration, financial damage, and in rare cases See, the problem with having multiple solutions other than their grade is that some of them are wrong. They're absolutely 100% wrong. Some of them are brilliant. They're amazing. They're the exact one that we should use. And the problem is that we need to know which one to pick. Right? Using them sometimes can be hard. Sometimes it's not they're all equal. Sometimes some of them are dead wrong. You should never, ever fucking do that. But sometimes there is one that is exactly right and everything else is wrong. And we need to decide. And this is where the community comes in. Right? And probably count on conventions generated by the community to know which solutions we should pick. So let's start with some stuff. I'm going to start with Cpan. Finding stuff on Cpan which is basically just a bunch of mirrors. Hosting code. Comprehensive pro-archive network. So it's a network of mirrors. And we want to search stuff on those mirrors and install things. To search we would usually use search Cpan or. Search Cpan or however is closed source. Which means that we can't really access it. It has very little integration with other services. And it's more of a memory muscle. When we're very much accustomed to go into search Cpan. It's not even a pretty new website. We're just really used to it. On the other hand we have Meta-Cpan. Meta-Cpan is open source. It is community based. It is community developed. And it has a lot of integration with various utilities and various tools and other services and other websites. Like where we host our code. Where we develop it versus where we upload it. And it has a lot of really nice tools to help us on our daily work with with our code. For example it allows us to see reverse dependencies. In the website itself. So if we search for a module we can see how many people actually use this module rather than what modules does it use. And then we can see oh a lot of people use it and some really serious things so I can count on it. And that's a very useful utility. There is a talk later on on the API of Meta-Cpan. It's going to be about Meta-Cpan API and Meta-Cpan client. Miki is giving that talk over there. So you should definitely attend that talk if you want to know more about what we can do with Meta-Cpan. Inheritance. So when it comes to inheritance how we build objects and link two classes together. So there's use-base. Everyone's used to use-base. It is old, unnecessarily complex. On the other hand we have use-parent. Use-parent is new. It's good. It's so new it's actually core since 510. How many people here use parent? How many people here use base over parent? Alright good. So hey check this out. You can just switch base for parent and it will work and it will be better. If you're using 510 and on you don't even have to install your inheritance. Objects. The thing with Objects in Pro and this is something that is hard to explain to someone until I found the right words for it. The thing with Objects in Pro is that well Pro 5 specifically is that Pro 05 really takes into account the underlying tenants of building a system. So we don't really have objects but it's something we need to build a system for Objects. And this is the weird part. People say there is no not exactly. We have what we need to build though. Because Pro always says I should at least give you the tools to build something yourself if not the exact product itself ready or ready. So Moose is the best way to write Objects in Pro. It is fantastic. It used to have much and you should definitely use it. However sometimes we can use Moose Moose is fantastic for processes that have to start and stop and start and stop often. Where you just have a very short life for the process and you want the loading to be as quick as you can. So you can use Moose. And Moose implements the majority of Moose except the middle layer. So it's two thirds. It's almost always all you need. Moose was created before Moose was written and the idea was to make it much faster which is why it's written in excess. The problem is that there's no interoperability at all between Moose and Mouse. If you have a role written in one and a class written in the other and you want to merge them, all help breaks loose. Moose on the other hand Moose on the other hand fakes everything that is required in order for Moose to think it's Moose as well. So they actually cooperate very nicely. So you can write a role in Moose and everything in Moose can use that too and it will work seamlessly. It's fantastic. So if you're using Mouse, stop it. Before we had that faking in Moose and we got the breakage of Mouse and Moose, someone wrote Any Moose. And Any Moose the idea was very simple. When the class loads instead of using Moose or using Mouse, use Any Moose and they can see Moose available in the memory. I'm just going to use Moose for your class. If I don't, I'm going to use Mouse and it's going to be very fast. But then you get, can someone point out the problem with this? Does anyone want to try? Has anyone used Any Moose? Just a quick question. Am I the only one? Seriously? Okay. So we have a race condition of loading order. So which module was loaded sooner? Did you by half instance load a module that Moose? Because now Moose is in the memory and now it's going to use Moose. You didn't oh, so it loaded Mouse. Now you're using it? That is still Moose now with classes. It's insane. Don't ever use that. And of course ingy.net who is bad shit and saying wrote Mo because why not have an object system that does the majority of Mo in a single line? So don't like don't ever use that. It's not don't ever. Like seriously if you're considering Moose get the fuck out of me. Is it most supposed to be compatible with Moose? Supposed to be is a really big term. Very big term. Enter YAML. That's all I'm going to say. Alright. Serialization. So when do we use serialization? Quickly XML. Never. If you ever have a choice, let it never be XML. XML fucking sucks. Okay. XML is the Java of serialization formats. Conversely, Java is the XML programming languages. The problem with XML is that it's written for a very specific purpose. Validation. No one does it. Except banks. No one ever. When's the last time you validated an XML schema? When was the last time you did this? About a year ago. About a year ago. Very very case. Usually it's not even then. It's insane. Never ever fucking use XML. And never programming XML. There's JSON. JSON is it's really built for the web. It's text-based. It's really good for configuration. It is your best default. It is very fast, easy to implement in serialization format. It's schema-less and it's fantastic. And then you have YAML. YAML is text-based. Also, it's very user-friendly until you actually get to a point where you have multiple layers and then spacing matters and throw Python. However, it's very useful for debugging. So if for example you want to debug a session that's going on, you can just print out the session data in YAML. It's very easy to read even though it's like just serialized in its function. So it's very useful for debugging. It can be used when you want to use it for user-friendly, for user fronting user-facing interfaces when it becomes too bloated and too big for YAML. And of course, if you're using binary, if you're working in binary, you should definitely know storeable. Storeable is our basic binary format. It is incompatible with pro versions, with storeable with itself, with the moon. It's horrible. There is, however, serial. Serial was written by Booking. It is insanely, insanely, insanely optimized and fast. It is compatible with different versions, different bits. It's fantastic. There's some really good bits to check out. And it really is an example of how to write awesome shit in pro. And it is so awesome that it's being moved to other languages. It's being ported. There is implementation in Go and I think other languages are working on it, too, because it is really, really good to really perform it. Moving on to user agents. So user agents, if anyone is familiar with that, basically allows you to have a browser without an actual browser. So you can make all the requests, you can understand all of it, and then you can work with that and you can scan websites to see if you can do that. The basic one is WP user agent. Who knows WP user agent? You can raise your hands. Fantastic. It's fantastic. It is very predictable. It is very stable. It's very useful. It's really, really, really good. And you should go ahead and keep using it. I should add mechanize. WP mechanize is a lot of nice wrapper around user agent. WP user agent. It gives you all the complexities of actually having a browser, like moving forward and back. It understands links, images, has objects for each one. It's really, really nice. You can just submit the third form with this user data. It's really nice and you don't have to do a post on it. It just does all that. So it's very good. It should be tiny. It should have as much as overhead. And it has fewer features, but it is mostly suitable for the tasks that we have. Or I should say it is suitable for most tasks that we have. So if you're striking websites, definitely use WP mechanize. If you're making htp requests, usually you should try htp tiny. Anywhere in between for other user agent doesn't use that much. But if you're using it, it's not that bad. Templates. Because, oh my god, templates. Who here has written their own template engine? Stop it. I did. Who here has written and then deprecated it? Right. So that's our templates. Let's start. HTML template. No. No. No. It sucks. Don't use it. Ever. Can it get an amen? Confirmed. Approved. HTML template sucks for a lot of things. It's fast, but it really, really, really sucks. There's a lot of things with it that are really fucking shitty. Don't use it. Mason. Hell no. Mason complains every possible thing in web programming into the same fucking template system. It is php, but on acid. Which is not better. It's just, it's really bad, but it's much faster. It gets from zero to sucks way quicker. Mason basically says, I'm going to put the controller, the dispatcher, the model, the view. I'm going to put everything into the view. And it sucks. It really sucks. So don't ever use Mason. Mason 2 was an attempt to fix it, but no one actually used it. Because people who use Mason usually are just stuck with it. That's why they use Mason 2. So they don't move to Mason 2. And it's not that big of a change in my view. There's some toolkit. It's a fantastic template system. It is really fast. It is comfortable. It is very useful for users. It's just simple to use. If you're giving it to a designer, HTML person, whatever, they can do it really easily. If you want to go nuts, you can use X-Lite. It is written in XS. It is in fucking insane. It is however batched crazy. If you want to spend the time to learn it, go ahead. It's fantastic. Web, which is where passion goes to die. Web programming, there's so much to say about Web programming. So, so much. And I am going to talk later about our status with it. The thing with Web programming, really, there is only one thing I want to say. Are you still using CGI? Don't answer. I don't want to know. If you are still using CGI, this is the only thing I want to say. You should use PSGI. You really, really, really, really, really should use PSGI instead of CGI. There's a multitude of reasons, and I explained that very well in different talks. You can talk to me afterwards about this. And seriously, this really is the only thing I want to say about Web right now. Just use PSGI. And people sometimes say, really? Seriously? Seriously? I can't use CGI? Seriously? I go like, seriously? Don't. And of course, for the last few minutes I'm going to talk about threat signals, CPU, parallel execution. However, we don't have the time for it. So we are going to do it next time. Thank you. There is a moment for one question. I think you're giving a talk right now, aren't you? No. Still five minutes? Five minutes. Okay. That guy! What is PSGI? PSGI is doing the Web correctly. Basically, it's a different protocol that allows you to separate your application logic from your server in a really nice way and then allows some nice features like mounting different applications, different paths, multilevels of dispatching, middle of the web, and so on. There are many levels of dispatching, middleware to wrap your code in it. Ruby has RAP and Python has WSGI. We have PSGI. It's really fantastic. There's an entire protocol in this and your time limitation for this and most of the web frameworks, including actually Mason 2, support PSGI. So if you're looking at the answer, Modulicious, Catalyst, Amon 2, and so on, wrap them in whatever code you want. And it just works. It's fantastic. It's amazing. Yes? How do we tackle all those legacy, all same providers and so on? I mean, they need to move on in order that we can get... For what? Any of the things I said or just PSGI or just CGI? No, based on CGI, PSGI just wants some of those shadows and providers. You can wrap PSGI on CGI. So that means that you can take parts of your code and slowly transform it. We should have raised that migration path. That's what I'm trying to say. What is the migration path? It really depends on what situation you're in. It can take me longer to cover. I'm not asking for that. Conceptual version. Conceptual version? Everything that is deprecated or that you don't have to continue developing, you keep it fully layered underneath PSGI and new developments are done in PSGI. Anything that is a hot path that is very important you can rewrite in PSGI. That is... That would be my approach. I think that's more practical. I'm trying to get it. Perhaps. That sounds like a talk. May I... May I just take a talk at the next workshop? Actually, I've been trying to do that and I want... I can get it done with a complex application. Well, the complex application is not a very good application. Well, complex applications require complex solutions. And I don't know if in a minute I'll have a complex answer. Is that better? Well, you might consider refactoring me. Refactoring requires a lot of profit. And... last one. How many years will it take before you have consigned to PSGI? How many? How many years will it take before you have consigned to PSGI? It remains to be seen. But I'll run that by you as soon as I'm ready.