So if another team is here, we can start. Waiting for you. So I think it's time already. So thanks for coming.

So I'm Gilles Forcada. I'm the head developer, out of two, but still. At the Freitech, that's a newspaper company.

These printed things that are still around. But that doesn't matter. So just a few questions. One of our main sponsors is about gymnastics and metrics. Let's do some gymnastics. So who knows? PEP 8. OK, fair.

PEP 257. Not bad. So do you have internal guidelines on your teams? Well, team aspect, so. Do you enforce them somehow?

Even if it's cake, that's enforcing. How many of you have been using or are using Plone recipe code analysis? OK, cool. Who knows that Plone API has a style guide? Cool.

So well, we are done. And the last one. Do you know this package called hacking? Anyone? Yeah, Timo, but you don't count. So nobody. OK. OK, so that's a package from OpenStack,

which is actually just writing in code what their agreements on code are. So there's quite a few nice things. Like, for example, that they have a guideline about if you

write a tool, you have to put your name next to it. So that whenever you want to see why that tool was there, you know who wrote it. Stupid things like that. Always add up. So yeah, why should we follow standards?

And grant me a far-fetched example, but anyone knows what's that? Most of them, it obviously didn't work. Yeah, sure. Do you know where it is? Not in Mars.

So it's dust on Mars, actually. So we are in England. So you probably know that they have this imperial metric system, imperial system, sorry. But the rest of the world is using something called the metric system. So the NASA got a joint venture with another company.

Guess which system they were using. And that thing crashed at an amazing speed and just burned $600 million, just because ones were using metric system and the other ones imperial system.

So while I was writing these slides, I got this mail from a completely unrelated project, nothing to do with blonde. It's about translations. And so that was a developer just trying to contribute. That actually was his first issue open on GitHub.

And just let me emphasize the last part of it, that he wanted consistent code, easier to read by humans. Because at the end, that's what it's about.

Yeah, breaking news. I was talking with Eric. Well, actually not. But yeah, since 2000, more than a year and a half ago, we have a guideline for Plone.

We have an approved guideline for Plone. So we showed all of those of you that still didn't know about it. There you go. Which is actually one of the probably better things. I mean, you probably were all of you on Eric's talk.

And you probably have seen those small snippets of how to get the user, how to get the tool, how to do things. Doing it with one API or not doing with it. And it's not just about doing it with Plone API or not. It's just like being consistent, being what you

expect to be, what you actually have. So just some more ideas on it, or some bad examples of that. Leonard Rachebro, is he here? No? So yeah, again, more than a year ago,

he wrote sanitizing Plone views. Not sure if anyone remembers that. So he look up how many ways do we have to create a bill in Plone. And now picture the people that were training these last days.

Once they get to learn maybe three or four of them. And then they start looking at code and how to do things in Plone. And they keep getting to, oh, so I know how to do a browser view, but shit, it's completely different.

That doesn't make sense. Well, OK, let's learn it. Now, again, stumbling up upon another way of doing it. So yeah, I mean, it's just like if you are baking bread.

Once you get to know a way to do it, you get confident that you know how to break bread. So you can teach others how to bake bread. It's not that difficult. You just have to get things. But then you say, well, no. You see, there's 15 ways of breaking bread. So what's good? What's bad? Which should be used? Which shouldn't be used?

And that's just confusing at the end. That's just making our lives worse. Of course, we don't have to have just one way. Of course, two or three makes sense. 15, I guess you probably agree that not. Just this is light for the sake of it.

You will have not expect to be in that color. You will have not expect to be in comic sans. You will have not expect to be the text at the top. So I just made your brain have to work a little bit more just because I just make everything different

and not the way all the previous slides were. Yeah, I didn't want to blame any or that anyone could feel blame for that. But if you look at Plone packages, they are,

yeah, I hear people smiling. So, yeah, yeah. I mean, of course, we have a lot of code. The code has evolved within a lot of years. So we need to, and now that we are getting to Plone 5 and later Plone 6 and whatnot, we

need to try to make things consistent. There's no way to make 100 developers work on a single file. And we have to have a way that doesn't matter if it's 100 developers. What if it's 1,000? What if millions of them do read it?

The thing is that once we get to a certain point, we need to make that file. Doesn't matter who of us wrote it. Should be just the same. Of course, the logic, the way to make it, doesn't have to be the same. But consistency, the way to get a call to the API,

it doesn't have to be bizarre. Because at the end, something that you read and say that to the ones that started Zope, they will probably, whenever they were writing that,

they were probably not expecting that in 15 years, people will still be using that. Just so whenever you are writing something, you have to always, just like Dylan was saying now, that you have, as a developer, you have always to think about who's actually using it. Because it's not that you are solving your own problem,

you are solving someone else's problems. So you have always to think that whenever you are writing something, that code will be written, will be fixed, will be changed, will evolve by somebody else. So the easier you make to that person, the less he will curse you.

Yeah, and if you get things like that, it's just impossible to work with. Yeah, and unfortunately, there's quite a few of that around.

Not all code is wrong, but... Yeah, and it's not just about... So actually, as you see, I haven't been talking about long recipe code analysis. There are some slides for it. But it's commit messages, the history log.

Can you understand what's going on here? No. If you are trying to debug why something happened, it's not going to be five minutes, going to be...

You probably will just say, well, someone else does it. I think that's from, that looks like kind of from kernel, not sure. But especially, and regarding still in git,

don't lie, please, that's bad. Didn't your parents call so? So the first sentence, it's what's actually the commit message, having grok, carry annotation from grok, carry annotation. And actually, it's just one line. It's an import done.

Turns out that that commit, it's actually having a new version of bootstrap. It's removing some lines on build out config and some other things. Still, when you are looking back at the git log,

you see that it was just adding a grok, carry annotation. So why build that configuration that you know that was there, it's not there anymore. And you are just looking at the file, at the commit messages on the history log and you don't see any notice about that bootstrap was changed or build out was changed.

But that's even worse. Unfortunately, it's not related to plon or zob or anything. Never ever do that.

So does anybody remember that bash had a security bridge? Guess what? I mean, just, I mean, it's, yeah, there's no words. Just, what's that actually doing? Who knows?

And all of that goes basically to cognitive load. Nice words. So basically, and I feel like repeating Dylan,

the more effort that you have to put on the more effort or the more noise that you see on a commit or in a patch, or just browsing the git log, or just,

just looking at the diff or anything, the more noise that you get on it, the more, the more white spaces all over the place and typos and so and so, you are, once you see a typo on a commit,

you're not seeing the commit, you're not looking at the, if that logic is doing what it's supposed to do, you are just seeing a typo. You are already lost, you already switched the context, you are already opening the editor and fixing that, or just writing back, hey, can you fix the typo?

Or can you just please keep Pepe and not just start using camel cases all over the place while anywhere else is being used? And that's just adding cognitive load on you. And if you are lucky and you can concentrate on what on every single task at the time

and not having to think about, oh my God, I have an appointment with a kindergarten or I have to go that place or the groceries and somebody in the company is also actually talking to me about something else and there's an email and there's something and whatnot,

seems that a white space or a typo or just camel case doesn't seem to add much, but at the end, it's just making your brain have to concentrate way more and have to waste more time when things shouldn't have to be. But fortunately, we have one recipe code analysis.

So yeah, as probably most of you already say that you have been using it, so basically, blonde recipe code analysis is just encoding some linters, so flake8, js-hint, css-lint,

then all sorts of linters like white spaces and what else do we have there? Yeah, lots of. Yeah, so that's actually a way to, at least you can run it locally,

you can run it in Jenkins, you can run it in a GitHub either locally on the server, so you get notification, so you get to review your own code. That's something that we maybe never put the stress on it

once you write something before sending as a pull request, do you ever take the time to just take five minutes and then look back at your code that you have been working on for a week to actually see it? Does it still make sense? Does it, you probably started with an approach, but then while prototyping that approach,

you changed your mind and then finished it in another way, but maybe there was a comment there that was still referring to the alt approach, there was maybe an import that's not more necessary. Are you creating some variables that are not needed anymore? Fortunately, we are using Python, so it's not that bad,

but we have to have, we in ourselves need to make a conscious decision that whenever we are sending something to review, a pull request commit, even if it's not in private projects or anywhere,

that will others look, will have fun, will course me for doing that. But of course, we have to bring that further. It's not just about Python,

it's not just about one of my last, like for example, ZCML. Do we, why everyone is ordering the properties on the ZCML differently? That doesn't make things, adding things easier, that doesn't make spotting things easier.

What about XML or templates? Somebody is using just two, just indentation of two spaces, somebody is using four. Somebody is keeping all the properties of an image within a single line. Somebody is breaking it on every property,

so having a multi-line statement, documentation, package structure. The way that we do testings, if everything looks the same, doesn't matter if today you are working on PloneReceive code analysis in CMF Plone

or in Plone App Content Listing, it will be just the same. You will expect to have the same patterns on doing the testing. You will expect the same variables to be named sort of the same. You will expect that in interfaces, there's all the interfaces, not in interfaces, in browser, in bullets,

in a folder called interfaces, why not? And that's just making your life a bit difficult. So the future, actually that's because of Timo, that he complained.

Like always. But you are right, as usually. So the problem that we have technically, so to say, in PloneReceive code analysis that it's kind of growing organically, and that's fine to some extent.

There's not much users of it or contributors, which you are welcome, by the way. But seeing that this hacking from OpenStack, they are just building a set of plugins on top of Flake8. So probably there's no code.

I cannot show anything. There's nothing. And actually it should work the same. But probably if there's people open to an open space, we could start looking at that and not just, as I said, not just looking at how to make,

how to encode all our agreements that we have in, that we are using Plone App testing, that we are setting everything in interface, and so and so and so, looking for things that are missing docstrings, but also code structure and so and so. So that's how I see the future

of PloneReceive code analysis, to be some kind of modular approach where we can just put as much plugins. And of course, every company has their own guidelines, their waste, I mean, there's no single, there's no single best way to do things. So if we make PloneReceive code analysis a bit more modular,

probably you will be more eager to contribute your own plugins to keep it either for yourself or maybe at some point make it if it's, if it's enough or if people agree on it, also in the wider Plone community

so we can also contribute those back. And that's it. Thanks for coming. So questions? Yeah. Do we have time?

What is hacker? What is hacker? Hacker. I don't know. Hacking. Hacking, okay. Yeah, yeah, that's the, so I didn't want to, as I have, we have a bit of time. So hacking is just a set of,

as I was saying, is a set of plugins on top of, on top of Flake8 and done by the OpenStack community. And the cool thing of it is that they, instead of just like pretending, okay, let's sit together here and decide what's the guidelines,

what should be the guidelines for OpenStack code, you are actually not allowed to contribute code to OpenStack that doesn't follow that, those guidelines. So you have to pass all the hacking rules and all the hacking tests. So the thing is that instead of forcing them, they actually started, as all the projects,

growing them, and then they realized, okay, when we are adding a to-do, we are putting within parentheses the name of the person that added this to-do. So let's enforce that now, because we see that we see as a wider community, we are using as a convention. So let's encode these conventions,

because at the end, if you have a Plan API style guide, which says imports should be done in this way or that other way, but nobody's enforcing it, nobody's changing it, why do we have that? I mean, yes, we have it, but you don't have a way to make sure that everything is following that,

because if that's what users expect, if that is what new developers expect, that all the imports are sorted in a certain way, and then you go from module to module, and you see that all the imports are completely different, then you say, well, that is still in effect, it's, anybody does care about it.

So that's what hacking the OpenStack community decided to, instead of upfront setting the guidelines, they were, they are always behind the community, and just adding the checks

that everyone is already agreeing on it, and then, of course, enforcing them, and not allowing others to commit if it's not the code like that. Do you know how the OpenStack community actually enforces their code analysis styles?

I mean, they are using Jenkins like we do, right? So do they have a pre-commit hook as well, like we haven't blown recipe code analysis? Do they allow people to commit to the master, or do they have a pre-check or fail to build? I didn't really check it,

but I remember seeing that they have Jared. So everything, it's managed through, and the repositories are managed through Jared, and the reviews happen in Jared, and there, I guess that, as with Jared, you can also orchestrate Jenkins, probably they are having that. Yeah, there are quite a few add-on products for that

that work with Plone, so that's pretty specific, with Jenkins, sorry. Yeah, that's probably pretty specific to their use case. We called at some point, we've been discussing with you a few times that we, at some point, we called, not allow anyone to commit on master,

and instead, let Jenkins do that, for example. So another reason to not allow committing will be, if we get at some point, I mean, I didn't talk about that, but now that we have still a bit of time, there's this, in the colonial sprint,

the beginning of this year, there was, and it's still an ongoing project to relaunch Plone.arc, and it's supposed to have wonderful things, of course, and one of those is having a roster where you have all the users, all the contributors,

but not only that, but we could also have kind of a roster of Plone packages. So just like everyone now loves to have the Travis batch and so on, we called at some point, maybe write packages about how they complain

are to our style guides, which kind of style guide do they use so that we can use that on Jenkins to see, okay, this is a package that it's supposed to be following Plone API style guides, so let's enforce that. So let's fail early, if a commit that it's, or a pull request, it's not a complaint on that.

If it's, let's say, product CMF Plone, which has lots of legacy code, doesn't make sense to, if it's not an effort that we do it in a single pass to now mix style guides as the worst thing that you can do, mixing styles. So at some point we could have kind of a level system where we can write packages about their complainers,

and this way we have, and we not only make Jenkins tell us about that, but we can also let everyone know that, okay, I'm in this package, which in its read me says, using this style guide, using that style guide, partially using this,

partially using that, and that it's an easy way so that everyone that has to contribute on a certain package knows what it's expected him to write, or she to write. There's a couple more. Oops. Okay, well, it's called Clone Recipe, but I assume I can use it on arbitrary Python

with XML code. Yeah, yeah, yeah. Actually, there were two things specific for Plun, are mostly tied to Plun, which was the ZPT lint analysis here, so for templates and the ATNN dud for translations,

if you are missing translations, but those we made them optional so that you can use it in any random project, Python or CSS, JavaScript. I mean, we also have a code analysis for those.

Do you have any recommendation on legacy projects or old projects that might not follow a code standard right now? Well, quite a few probably. So, but yeah, I mean, so yeah, the question, what can we do with code not following Plun API start,

which there's quite a lot. We should do one package at a time, so either convert them, if it makes sense. I mean, we are not going to break backwards compatibility just for camel case. That's for sure.

And maybe at Plun six time, why not? Um, yeah, 16, what to do with those? See what, yeah, I don't have a bullet solution for that. But so the thing is keep consistency

with the related code, that's for sure. And if you are doing new things, of course, try to use best practices. There was one here and one, okay. Just curious what you were trying to illustrate

with the graph of all the mergers. Oh, well, that, as I'm working our website, for example, the Fright Act, we have 15 packages there. And we are, it was started by three persons.

When I joined the project, out of these three persons, there was just one left. That person left a year later. At the time that I joined, another person joined me. So we were back three.

A year later, I was alone. And now we are two. So within five years, that has been four, five, six persons, well, seven, Timo was also, yeah. So there was, so the thing is,

if from time to time I stumbled upon code, which I don't know why was there, I don't know what was the functionality of it, why was the intention of that, and I'm just digging in the code, in the Git log, to see all the commits related to that file

or to that specific module. And from time to time, I'm just, I mean, if you have a consistent lock, commit locks, you could guess, okay, maybe that commit is interesting me. But then you open the commit,

and as I said in the other slide about the lying, I see that there's a commit that it's changing that file, but it's also changing 15 completely unrelated files. And then I'm okay, do I have to read this more than 1,000 commit just to see if that file had something or not,

or what was the intention of that? So if you have a clean history, it's always easier to see why things were done that way. So it's not because they were merges, that's not the problem for you? No, no, no, I just wanted to find something that will look a bit funny and not easy to understand.

Yeah, yeah, merges are fine, of course. There's one here, anyone? I have a question about kick-starting new developers or developers that don't know the conventions and everything, so I guess the most important thing

is about documentation, so getting documentation about clone up or clone recite code and all of them, the coding conventions in the official documentations, and at least some example how to configure the three, five most used text editors

for developing to do it like that, and probably that could be a good thing for sprints to write something like that. Well, your last point about how to configure editors, sure, that's missing, but what's in code,

just like in the hacking package that they are just encoding what's already an established agreement between the OpenStack community, that's the same that we are trying to use in clone recite code analysis. Nearly everything that's not a flake-a check,

it's what it's already said on clone API style guide, so the documentation sort of... So it goes in, so it should go into dot clone org? Well, a clone API, I think it's already there. So the documentation about what's being checked, it's what's being done, it's not everything

that's done in what it said on clone API style guide, but that's what we are following. There was a question, anything over there?

No, my point's exactly the same about documentation, and I did just have a quick look, actually, for those style guides, and I couldn't easily find them within the docs.clone.org, especially there's a new area, there's an area called developing your own add-on, and it should be the first thing there, really, to help any future development, any future developers using clone.

So, and the documentation is good, so let's just promote it. Yeah, I guess the documentation will, teams will love to have more help. There's an open ticket for us, and the first ticket reopens. Okay. So, you won?

He will give you cakes. Not saying. Any more questions? Then, let's have a break.

We'll see you next week. Have a good day.