 I'm Esther, I work for May.com, a UK company that design and sell home furniture online and in other parts of Europe as well. And I also apply to an Italian organizer and developer. I recently joined to Stradbury GraphQL as a core dev and also as a poetry packer manager contributor. So with this organization, I have seen a lot of tools and automation that I think they are really great and help to have a better developer experience. So today I would like to show them to you. And oh, we are sale, by the way. And so you can go on May.com and check if you like something. And I should also mention that my team has recently fixed a little thing about island postcode validation. So now we can ship also to Ireland and other countries. So go and check online, please. So have you ever been in this situation when, so you're working on a feature, you are writing some code. And I think you finish your work, the tests are passing locally. So you are ready to commit your code and push your code. And at this point, I think we have some time to kill because the pipeline took a while. So we can go out for a walk, relaxing, get distracted. At some point, we will remember that we have to work and we will go back on the pipeline and see that everything is read. We forgot to run the linters locally, so the pipeline warned us that the code quality is not reached. And it's facilitating and we should have learned our lesson. And next time, we will remember to run the linters. But the truth is that we probably forgot anyway at some point. Also because sometimes you do a silly change that doesn't, shouldn't change so much, but it's that silly change that breaks black or isert. So we probably lost a bit of time because the pipeline took a while because we never optimized Docker, so on. Anyway, we can optimize a bit the stuff and introduce our first tool that is Precommit. Precommit is a multilingual package manager for Precommit hooks and it will run automatically on every commit, before every commit. So we have just to create a little bit of configuration and there is a nice command, sample config that we create for you. And we have to run Precommit install. So this is our configuration file. You can see there is the repo. There is the version because Precommit will install the stuff in a separate environment and everyone in your team will have the same version. And yeah, and there are the ID of the hooks. So there are many things you can add to your Precommit configuration. And I think in a Python repo, you should always add at least black eyesort and flake eight or pylint. But there are many and the list is very long and you can check online. Those are some of my favorite. So there is PyAgrade that automatically upgrade the syntax to a newer version of Python. So our code is up to date and hopefully it will be a bit faster. And there is a flake eradicate that will notify us that we left some commented code. And the last one is a nice one because flake eight or pylint only tell you that there is an input or variables but they didn't remove it for you. Instead, out of flake, we removed it automatically. So what else we can add? The list is long but it's not always about code quality. It's also for our safety. Because there are some dangerous stuff, some secret, oops, sorry. Yeah, this is the correct one. So it's also for our safety because we are very careful to not commit some secrets and dangerous stuff. But the truth is that when it's committed, it's kind of too late because it will leave it there kind of forever in your history somewhere. So this is just an example of what type of stuff you can add to your checks. Why we should add precommit? So I'm trying to answer this question. And one of the benefits is because it will help to identify the silly issues like leaving some of the bugs in the code or missing a new line at the end of the code. Also because this stuff only appears during the code review because GitHub did a very good job to emphasize that you're missing a new line at the end of the code with this tiny icon. And so in my organization, there are, I think, a lot of these comments. And if you use precommit, they will, you will remove earlier. So we can concentrate only on what matters. So the core review, the code, what is really change. Also, to me, it's a bit awkward sometimes when I say this little mistake, because I wonder myself, should I bother to notify the author, or I should look in another way? Because the code will work anyway. So maybe I already commented a lot of stuff in the pull request, this big, and yeah. So we can avoid this stuff. Also, it's because nowadays, we have a lot of code, it is not only Python, you have no matter if you have a monorepo or microservices, we have Python, we have Terraform, infrastructure, or Ansible, some bash scripts, some markdown, because we have documentation, JSON file for fixer, anything. So it's multi-language, so you can add a hook to format any code that is going to be read. And yeah. So I tried to ask myself why people don't like it, because of course, I'm a bit biased, because I love this tool, so it's difficult for me to identify why. And I wrote a tweet, and maybe my bubble already use it. Anyway, I think one of the main reasons is because people think it is slow, but I don't think it's the case, because of course, the first time you add the precommit to your repo, and you promote all your code base, of course, that can take a while. But normally, it will take only a few seconds, especially because it's incremental, so you precommit will run only on the code that you are about to commit. And also because, for example, if you commit some Terraform code, it will run only the hook for Terraform, not for Python, so it's very quick. Anyway, it can be that some hooks are slower than others, for example, Pylint, MyPy, that hooks that has to analyze the code can be slower, of course. And you can skip it, or you can run one at a time. You can skip there entirely. And it's okay anyway. For example, if you're doing per programming and you commit frequently, you don't want to bother to the code quality, so it's okay. You can run later, if you want. Yeah, so there are options to mitigate if there is this problem. Also, as you mentioned that they add a manual stage, so by default, precommit will run on every stage. There is not only commit, there is precommit, push, post, commit, pre-merge, post-merge. There are a lot of them. And they introduce it on a stage, so if you have something that you have to run only once in a while, you can run it manually. And this is a nice feature. And yeah, the only thing now that we have to remember is to run precommit install when you clone the repo. The only thing. We can potentially avoid if we do a nice trick. So if you add a g-template in your home directory, in your g-t home default directory. So a g-template is... So when you clone or initialize a repo, there are some files that will be copied from this default directory of g-t into your .git directory. So you can add a little script in your default directory, and it will be copied, and it will still precommit for you. So after, you don't have to remember anything. And if the repo you clone doesn't have precommit, doesn't use precommit, you will just print something and leave it there. So cool. So I think one specification is needed because using precommit or non-using precommit is your personal choice. So you should not force your team to use it if they don't want it. And I think at the end of the day, whatever makes you productive, it's okay. So choose what you do, every commit, every push, there are many options, whatever fit for you, it's okay. So whatever we... What else we can do? We can run, of course, on our pipeline because we want to double check the code quality, of course, and there is also precommit CI. And it's nice because precommit CI can also edit the code for you. So you can also fix the hooks. So check it out. And I think for public repo, it's free. Yeah. What else? So if you, like me, in your organization, have a make file in your project, so every team can decide what to put inside the make file. So we ended up with a bunch of commands that they do always basically the same thing. Anyway, so at this point, if you have precommit, I don't think we use them anymore. So we can clean up our long make file and, yeah, clean it up. So we have one tool to run the whole. And that means that we have a lot of hooks now. So every hooks need a little bit of configuration. And this configuration is stored in a file and usually in your root directory. So that means we have a bunch of .file.csv in your root. So we can think about cleaning up also the repo and your root and move it in a special file called pyproject.tom. So what is pyproject.tom? So at the beginning of Python, there was only one tool to build packages. But after some point, set up tools came out and created some issues. So this PEP 518 managed to solve these issues. And after, every project can specify which build system they want to use. There are many. But what's the matter for us? It's because there is also a special session for tools. So we can add there the configurations. Not every tool allows you to use pyproject. Many of them are already integrated. This is a very important part of this functionality. Other one are developing or migrating to this. But you should check their documentation if they support or not. I talk about, specifically about pyproject.tom because I want to introduce another build system that I think is amazing. And it's called Poetry, a tool to manage dependency, virtual environment, packaging, versions. So some languages like Go or Rust has a tool that manage all the aspects of your project. But Python doesn't have a tool like this built in. So Poetry managed to compensate this. And what does it mean for you? It means that you can create the setup py. That is deprecated, by the way. Requirements, set up CFG and other files that you have. And have only one pyproject.file. So how it looks, it looks like this. Hope you see it. So you can see at the beginning there is some information about metadata, the description, the packaging. We have the dependency, the specification of the dependency, and they are grouped by the production dependency above and below the dependency. These are only the primary dependencies. So those you add to your project. Because when you install, when you do poetry.install, it will create another file called poetry.lock in there. You have this exact specific version of your dependency. So in your team, when someone installs the project, it will have the same versions that you have. So this is easy to debug the stuff. Okay. I should mention that poetry 1.2 is coming very soon, hopefully. And it will introduce some nice features like group dependency. So until now, you have only the production dependency and extra dependency. After that, you can decide how to name your group, how to group and name your dependency. So you can create the test dependency, the docs dependency, deploy dependency whatever. It also has a plugin system. So it means you can customize this tool on your needs. So it's very interesting. I'm very looking forward to this. And yeah, this is how it looks like. Poetry install is very fast because it's parallelized. And there are many commands. So poetry add with all dependency. Poetry update. Poetry run your, for example, if you do a poetry run Python, your script, we will run the script in your environment without the need to activate your environment. And this is kind of cool because you don't have to activate and wait. It can be slow. I'm very slow when I have to activate the environment. So this is really great. And of course, you can publish the package if you have a library on PyPy. Just with a simple command. So yeah, the very last thing I have to say is that Jet2Brainz has done a survey recently. Hope you can see it. It's wide enough. But yeah, there are many questions in it regarding the development. And it's very interesting. I was very surprised to see how much people are using poetry already for dependency, for packaging, for a lot of stuff, for written environment. So it's kind of, I think the third tools depends on the need. It depends on what you are looking for. But yeah, it's pretty great, I think. Okay, I don't know what's happening. I finished my talk. I don't know why it's not. Okay, leave it there. Thank you so much for your attention.