OK, good morning, everyone. The long line at the entrance to the center complicated things a bit, so we're off schedule. So I'm going to try to compensate a bit for that. And well, so I'll just get going.

My name is Carlos de la Guardia. I've been working with loan and before that and so forth since 1999. So I've seen all the evolution if you were at the keynote from Eric.

And so the in memoriam at the end of things rolling up, yeah, we've been through a lot. And in the process, we've learned that loan is not always what you want to use for all the things that you want. When we were starting with loan,

it was like, hey, let's just loan for everything. And if we have a business application, yeah, we're going to get loaned into that. And let's use loan for almost static sites. It doesn't matter that request will take 20 times longer to complete. So over the years, we've been learning about that. And also, the world of Python web development

has improved considerably. So right now, we have several powerful web frameworks and several ways of doing things that we have learned over the years. And that's what I'm going to talk about. Like I said, loan is great. Loan is a great CMS. And you can get lots of things done with that.

But sometimes, it's just not what you want. For starters, loan is a CMS, content management system. And if there's no CM in your S, then probably, loan is not exactly what you're looking for. Content management is what it's all about.

It has lots of features. But those features are geared into making a good CMS. So sometimes, we have customers that say, yeah, OK, I want loan. I want a loan site. But that feature, I don't need them. Workflows, who needs that?

I don't need this. I don't need that. And you end up spending half the time in the project just turning features off and moving them out of their way. So lots of features can be good when those features support what you're trying to do. Also, sometimes, it's just not the right fit.

The customer is looking for something different. So they will go, well, yeah, that's very good. And I like it. But how about we could do this, and this, and that, and that, and all this and this and that doesn't have anything to do with the actual loan. So you can do that. And we've done it. But sometimes, you just add a lot of stuff

into a system that is not built for that. And of course, there are many frameworks that are popular these days. And sometimes, customers will just want to, hey, why don't we do this just like, for example, Django does? Well, this is not Django.

This is Plone. And we do it this and this. No, no, no. I want Plone. I like Plone. But how about the relational database? OK, you don't want Plone. So sometimes, when you have a project, and this is something that happened to a lot of Plone companies at the beginning, you

want to everything, every project that comes your way, yeah, we can do it with Plone. And that's not good. It's not good for you as a developer, because you end up doing something that we call fighting the framework, which is there are these features that are not useful for you. And you have to program around them or just plain move them

out and fork stuff so that they don't get in the customer's way. And that's not good for you as a developer. You will take more time doing things. You will get more complex development. You will end up costing more to the customer. It's not good for the customer, because even if you get the thing that you want at the end of the day

out the door, you will have probably substandard features, because you mangled Plone to do something that it was not built to do. And you will probably get bad usability because of the same. And it's also bad for Plone, because it gives Plone a bad reputation. The customer will go, oh, yeah, we had this project with Plone, and it didn't work,

and it was a nightmare. And people who listen to them talking about that, they won't know that it wasn't really a CMS project, and it was a developer trying to shoehorn something into a small space. They will only know that Plone is not good. So that's why I think it's important to discuss

these things. There are some common situations that you run into when you're building Plone sites as a company. Customers can come to you, or if you're doing it inside a university or a company,

departments or groups inside the university can come to you and say, we need this, and we need that. One common request that we get is we have this static site, and it's perfect, but we want to move it. Corporate wants us to move everything into Plone, or we need to move this into Plone.

That's one case. Other case is we want Plone, but there's this department that needs to access some information from Plone. We don't want them to have administration rights or anything into Plone, but we want them to have these views into the site.

So that's something that not necessarily requires Plone. We can work around that. And there's also the case where you want a complete different application. Even if you have a working Plone site, you want something that works with the Plone site, but it's not the Plone site. And you will want something else to work in conjunction

with Plone so that you get, for example, the same users, the same indexes, the same database, and stuff like that. So that's another use case where you have to analyze your options carefully. The other one is you need a completely different thing, and it's good from the beginning to be sure that Plone could or could not be what you want,

but you want to really analyze things beforehand. So the first case that I mentioned, when you have to move a static website into Plone, your first question has to be, do we really need to do this? Can we just put it in Apache or something in their directory

and have people access it? With a good front end, you don't really have to worry about people confusing URLs, or you don't have to give them the URL. You can put a link directly from your main page. So that's a possibility. Sometimes, though, you want to keep not just want

to show that, but you want to keep the information from that static website in your own, for example, in your build out that you have, and you want to take control of it. That's also a valid use case. In that case, you can just use this trick of adding it as a resource, a directory

resource inside your site, in your Plone configuration, and then access it with a URL that you can also mangle from the front end. And you will get a seamless access into the site without having to get all the work to move everything into Plone. Sometimes you just have to do that, copy and paste stuff

into Plone, though, like I say, if you can avoid that, it's best. But for small sites that we've moved sometimes, well, you can create a document and just copy and paste stuff in there, and it also can work fine.

For larger sites, migration can be troublesome, especially if, have you heard the term spaghetti code? If the HTML for the old site is not well-structured, to put it mildly, you will have a lot of trouble moving it to the other.

That's why it would be really, really neat if you can just avoid that and put it up front. But there are Plone tools like Transmogrifier that allow you to do migrations in a structured way, even if you have to get into messy HTML to get there.

A more interesting case is where you want a simple application to get information from Plone. You have probably these users that are important players in your organization,

and they want access to some information. But you don't want them looking at some information in Plone, or you don't want to get all the trouble of training them to get that. They just need some information. And you don't want them to go, or they themselves don't want to go into each and every site

and log in and get that. Probably you have multiple Plone sites. So sometimes it's good to create a simple application. It can be a simple web application using whatever technology you want. Obviously, as Plone developers, we usually like to work with Python.

But as web developers, we usually have to work also with JavaScript. So there's almost no escape from JavaScript these days. So you can create a simple application with JavaScript that uses, for example, Plone REST API, which is a pretty nice product that allows you to talk to your Plone sites and get information using requests.

And that could help you get information out of your sites and create, for example, a simple dashboard where you can just talk to Plone using even JavaScript on the client side purely and get some information from Plone and display it on a nice web page.

So that's a nice way of getting things done. Sometimes the information you want is not really there, like accessible to Plone REST API, because you want, for example, a specific search, or you want to combine information from several sites. In that case, some things that we have done

are getting into the Plone site, adding some views that are specifically for a JSON client, for example. So you create a couple of Plone views that do exactly what you want, and you use the APIs to get access to those views.

And you can get pretty customized dashboards in that way without having to get into more elaborate Plone development. If you can avoid it, please don't use web scraping. That's a nightmare for you, and there's really no sense.

We have tools that can allow you to get information. Like I said, to create that application, you can use lightweight things. Like I said, we like Python, but you could use anything if you really want to.

I like JavaScript, which is good. And usually these days, Python and React, JS, or Angular are pretty good matches for getting your site going. The more complex case is when you have a Plone site,

and it's a complex Plone site, and you want to integrate with other technologies. That's a super common case where you have things like Salesforce, or you have a front end shopping cart, or you have a database, or a common user

store somewhere else that you need to integrate into. And so in this case, you would need to look much deeper into the requirements. It might be possible to do some of these things with Plone, but it might be a lot easier and faster to get it doing with other tools.

So it's very important before you begin to do something like that to really get your requirements straight. And if you're working with another integrator, for example, if you're working with Salesforce, you need to get your Salesforce people,

and your Plone people, and everyone in the same place, and try to get a plan of what features you will need from each system. If there are other pieces, like, for example, an ancient library system that you need to integrate into what you are doing, you have to do your best to get the people that

handle those systems, and get them into the same room, and try to get a plan of how to talk to it. At least find out how to talk to the different systems so that you are able to get that going. In this case, using REST API or something like that might not be the best bet, because sometimes you

need a lot of information from Plone, and you have to coordinate across different systems. So it would be better in this case to do something different. I mean, if you are going to go to Plone every time you need something, it can get pretty expensive. So what we do usually is synchronize information

from Plone into some other system using Celery, for example, or other queuing systems. Also, memcache can be a good thing. If you move some information into that, you will get faster responses. So usually, you can get a process going at night

to synchronize information. It can be daily, or for some kinds of information, it can be weekly. It depends on the requirements, but that's a good strategy to do. One other thing that can be useful is to use a shared catalog among different applications

or sites, for example, using Elasticsearch or Solr. Those are very good tools. They are fast and built for that, and they allow you to do things that Plone's catalog doesn't, for example, searching suggestions or other nice search things.

There's a great case study of this sort of situation at this conference today at 2.50. David Glick will be giving a talk about integrating Pyramid and Plone and lots of other things together into a large project.

And you would do good to go and look at that if you're interested in this subject, because that's a really nice use case, and it goes into depth that I cannot go at this point. The other case is when you just

need a completely different application. Like I said at the beginning, you are not forced to use Plone for anything. We won't think less of you. We won't feel sad that you chose not to use Plone for a specific application, because we know that a happy customer that is doing what is best for the business is better than forcing everyone

to use Plone for everything. There are many options. One way of getting a handle of what exactly you need that we like to use is decisions. How many decisions do you want your web framework or your web application to do for you before you even start?

There are full stack things like Django that already offer lots of functionality out of the box, but they already picked an ORM. They already picked several template technologies. They already picked several tools that are part of the arsenal for Django.

So if you're going to use Django, you're going to have to work with that. So it's good if before you get started, you know if you want to go that way. There are other frameworks that do almost nothing, just give you some views, templating, and that's almost it,

like Flask, for example, and access to a database. And you have to weigh your options carefully and decide how much do you want done, how much can you take that's already ready for what you need, and then what we like to do is find three or four alternatives

for a given thing and create a table and compare each one along the axis that are more important to you in a project. So you create that, then you go to the customer,

and you lay out the different options, try to make the best pick. If you have people who like that or a development department, it's good if they try stuff from now and then. For example, for Python, we've

found that it's really, really good if you can send people to PyCon or a conference like that, because they get a huge view of what's available and what people are doing, and that helps. Even if you're using just Plone, having a connection into the larger world of Python can be very helpful to decide exactly where to look

or what to look for when you are presented with a case where you have to do something else. So make a short list, try out things. Those things are useful. When you decide that you have to use something else, what you use depends on the type of application.

You can use, like I said before, Django is a very powerful thing that's ready to roll and can get you rolling right away. Pyramid is another framework that is very powerful, but it's much more flexible than Django. Flask, I put a question mark, because in our experience,

it's a good framework to get started quickly with something. But if you want to grow, you almost always have to just throw it all away and get started differently. Even Flask's own documentation states that when you want to do these larger things,

forget about these things that we explained in chapter one and let's go with this. So that's why I wouldn't recommend going with Flask if you believe your project can grow. For one-off applications, Flask is very good.

Well, sometimes you may know that sometimes one-off applications tend to last much more time than intended. So in our projects, we sometimes encounter one-off applications that have been running for five, 10 years. So you have to be careful with that.

There are many options, and this is where I, I'm sorry, this is where I make a shameless plug. That's a book from O'Reilly, but it's free. So you can get it right away if you go to that URL.

I wrote that, and it was published this year. So it's recent information about the different Python web frameworks available. It covers in little detail most of them, like 40-something, 40 frameworks,

but it goes into detail in the most important ones, according to popularity of downloads on the Python sites, which are, for example, Django, Flask, and Pyramid, among others. So if you want to take a look at what's available there,

that's a good place to start, if I may say so myself, sorry. And this is the book that you get. It's a PDF, so you can download it and take a look right away.

I try to get some common criteria to look at the frameworks, and then there's a list of all the modern frameworks that are there with different criteria, including a relative popularity rank that I gave it,

so that you get a sense of how many people are using it. More stars mean more users, and whether it's compatible with different versions of Python and all of that. So as you can see, there's lots of information there.

And then it goes into detail with Django, getting you code samples and stuff about what's good in it, when you could use it, and more. There's also Flask and Pyramid, which are, well, there's also Tornado, for example, for Asynchronous, and others.

So it's, at least it will let you know how the field is doing with these days. Going back.

Having said that, we believe Pyramid is a good fit for Plone developers, for several reasons. One of those is it's really part of the family. Pyramid developers are, wear soap or Plone developers.

So when they developed Pyramid, they took away some stuff that they like more about soap, about Plone, and they also took away some tools. So for example, the page templates that you use in Plone, they are the same that you can use in Pyramid.

So that's a good thing from the start. And you have similar concepts. The way we talk about things in Plone, when there's the mechanism that we use for traversal, the context that we use where we're using a view in programming, the concepts that are part of the soap component architecture

that uses, that Plone is based on, all of those things can be used in Pyramid. So if you are going to work on both things simultaneously, sometimes it's good to have a common ground, and Pyramid gives you that. Pyramid's also super flexible, so you can mix and match several technologies pretty easily.

And it's a great, great framework for gluing things together. So when you have those integration projects where you need to talk to different pieces of software here and there, Pyramid is a very good choice, we think.

One thing that it, where it excels, is it's a backend for a React.js or Angular application. And it's, Pyramid has great support for having different views that render JSON automatically, for example.

And it is very, very, very nice fit for a JavaScript-heavy application, and especially front-ends. Like I said, if you go to this case study at 250 from David, you will take a look at this and other interesting things about Pyramid.

And well, that's it for me. I wanted to get the conference schedule right, and I think this does it. So please help us improve.

There's a Ruby application that you can use to give your opinion about the conference. And well, my name is Carlos. That's my email and my Twitter. And if you have any questions, now is the time for that.

Thank you.

Yes, Kim. Well, we haven't really started anything in Plone

recently that we don't feel is really, really a nice fit for Plone. For a number of years, we've been doing this move it to something else, if possible, philosophy, because we found that it works really good for us.

So I wouldn't have a completely new case that I can think of. I don't know, Sal, if you can think of something. Yeah, yeah, because if you really are careful in what you want to do, what we've had recently is several cases where we've decided to go

with something else right from the beginning, or at least present to the customer some options. I do have a case where we had a customer that wanted to go with something else, and we suggested that he consider Plone, and he refused.

And we thought that Plone would be a good fit, so we ended up doing that something else. So that went in the other direction.

Yeah, yeah, you're right, it's probably not surprising that since we are Plone-focused company sometimes,

and Django, for example, is so popular, sometimes we end up in the other side of the coin. It's like people want to use Django, and we probably don't want to use it for several reasons, but sometimes the customer just wants to use it, so there's no way around that.

Yeah, especially for the very first case I presented,

that would be super easy to get something going with the headless server and a JavaScript or Python-lightweight front-end. I think, yeah, that's a possibility. And since Plone CMS, like you say, is headless, and it has a set schema for content,

there's nothing stopping you from using Pyramid, for example, to work with that as well. So they can work, I think they can work together, and it will be something else to consider when starting a small application. Yes?

Flask versus Bottle, oh, okay. Well, Bottle is intended to be just one file thing that you can easily move somewhere else

and get your development going. They don't, in general, a Bottle application will not even have modules. You just have a simple file and then try to get everything done from there. Even Bottle developers say in their website that if you need something more complex,

it's probably better to use something else. Flask could be a good option for starting something. Like I said, Flask is a very good framework and people like it very much, but it's really not built for it. It has some problems with large deployments because of the way it's constructed.

It has globals and it has some other things that get in the way of proper testing or proper, when you expand your application. So that's also something that, like I said before, that's on their own book. The Flask book tells you if you learn to do things this way, the first six chapters, but from here on,

we're gonna do it this way because of performance. So Pyramid, for example, it's always the same. No matter what, you can start with a small thing and you can grow it to a large thing and there's no impact in that sense. So between Flask and Bottle, I would say Flask is a better choice right now

because it's more popular, lots of people use it. It has lots of extensions that you can use and it's very, very good for small applications. So if that's what you want to do, a small application, for example, a lightweight thing to connect to Plone, that's a very good way to go and Flask is a really nice choice in that regard.

I would go with that over Bottle. Thank you very much.