Lightning Talks (Tuesday) with Andrew Mshar

Speaker 1: Hello, my name is Chrissy. I work for Six Feet Up and I'm going to talk about our experiment with vibe coding. This is just a term that means we let AI do all of the work for us. We've been working on using AI more to help us with development and to see how helpful it actually is. We spent some set dedicated time on a small project recently where we split into three teams. and allowing each team to kind of work on their own implementation of the project. Each team was given the business requirements and we all started with SCAF so that we could have a quick start since it builds up the skeleton for a Django site and gives us a development environment. And then from there we all tried various AI tools like ChatGPT, Claude, Goose, and Gemini. Really the purpose of this was to ensure that everyone on our team had had some AI experience just to see what it was like, make sure.

Speaker 1: Also, that everyone was set up on our company account because that's configured to not share any of the information that we provide as part of their training models. I will also note that the state of AI changes very quickly, and some of the things I'm going to talk about are probably already obsolete. So, some of the pros of using AI for writing code. One of them is speed. So the development moved faster overall. AI had no problem taking care of simple code that takes developers a bit of time to write by hand Also, diversity. AI assisted with many parts of the project, such as writing user stories, creating GitHub issues, and drafting commit messages for the code that it wrote. The knowledge. AI is great at building new features for your site and demonstrated some strong understanding of Django, even recommending best practices when given a choice of how to implement something.

Speaker 1: Then for prototyping, uh, is great for quickly generating a working prototype. And then while learning from mistakes while prototyping, the specs could then be refined iteratively So it's no big deal to start from scratch with a clean rebuild that is using cleaner requirements. And then testing. AI does a decent job of writing test cases, which you'll find are absolutely necessary later. So now some of the cons for using AI for development. Version mismatches. So one of our team was trying to build with Tailwind 4, but their AI kept telling them to use Tailwind 3 code, which wasn't compatible. And some looping frustrations. During debugging, sometimes the fixes suggested by the AI didn't actually solve the problem, and that would put us into a loop of asking for a fix and then finding that it still wouldn't work.

Speaker 1: Instability. There were occasional regressions and random breakages of things that had been previously working We found that AI is kind of weak with complex code sometimes. It struggled to build on on on top of existing code bases, especially when they had a lot of logic and moving pieces. There's some collaboration friction. So the team that I was on, we split up with the work between the four developers, and each of us were using AI to build a piece, to test, and then commit. And this led to frequent git commit conflicts and overlapping work. And since none of us had actually written the code, we weren't familiar to be able to easily fix the conflicts. And that kind of leads into my next point, was that with that low-code familiarity of the developers, we really felt less ownership of the AI-generated code.

Speaker 1: AI seems to suffer from some task overload. If you give it too many instructions at once, it tends to skip some steps or leave things incomplete. And we'd have to ask it to, you know, go back, check your work, fix the stuff that you had missed, for it to then do all that again And then blind spots. There were some simple tasks that all the models seemed to fail on, such as like knowing when to use a positional keyword, positional argument versus a keyword argument. So now the takeaways that we learned from this experiment. The first one is to blueprint first. Focus on building full specs before you start to write, or you write code, or whoever writes the code. But get all your specs written first. You can do AI, use AI to help you with this part.

Speaker 1: Be as specific as possible in describing the work you want done and what versions or frameworks of add-ons you want to use. include the guardrails to keep AI from just doing whatever it decides. AI tools can be a huge help, especially once they are trained to follow your team's processes and best practices. Work in small steps. Doing one small piece at a time makes it easier for AI to follow instructions and for yourself to make sure that each piece is working. Have AIREP unit tests, so you can then run them with each commit. Human code review and QA are still necessary to make sure that your code is solid. And success with AI really requires familiarity with the tools and awareness of their limitations.

Speaker 1: So my recommendation if you haven't used AI yet, get some practice. Start with a small one-off script that you know where the code doesn't need to be perfect, maybe a personal project or something. So come see a setter booth, pick up swag that wasn't in the swag bags, and we're also going to have a blog post about this coming soon. So thank you

Speaker 2: Good after all. My name is Rizwamansuri. I'm an application architect for Global Logic. So we are the service provider for uh one of the departments in government of Ireland. And recently we did the project for migrating that legacy uh Django application into the Wactel. So I'm gonna Walk you through this is uh their migration environment. So this is the legacy system. And I think one of the asks for us to keep the front end as it is so there is no movement in terms of uh the The front end needs to be changed and also they're using the design system, so we need to be very limited in terms of the the front end, but the back end we need to completely rewrite from into Wagtail So I'm just gonna make the couple of uh

Speaker 2: problem statements here. So this is the the home page, then if you go to the department page. their list of a lot department here with the agency and then if you go to one of the department pages this is their home page and I think this pattern like follows throughout the website and then this is one of the uh kind of paste type consultation and if you see on the URL it doesn't reflect the which department it belongs to and it just says the page type and then some Gibriss uh kind of uh string and then the some kind of SEO related uh slug into it. So I think this running this website they they they write a six microservices and uh uh the cost of this site to run every month they were p

Speaker 2: paying ten thousand euros to AWS so and also the maintenance wise any changes that needed it requires three microservices to amend, deploy, which is mass. So I think they decided to move into the Vectel. So we did take uh help with the Torchbox guys as well, along with us, and there is some small development team inside the OGCIO. So how we did it. So I think I just forgot to mention about the they have this like a single list of interface. So this is kind of a back-end the content editor C where they had about 283k object into it. And if you see is there there's some press release.

Speaker 2: So all the item type or page type they listed into here. And Also all the publisher listed here. So if they need to create uh the content, they choose the publisher and then they write some kind of a Django application So they they were saying us this is the CMS, but we don't take it. This is like kind of plain CMS. And uh one of the editing, they have this full of short codes that they insert into the into into the editor so if I type take gmail. com so I just want to see the demo kind of uh I don't know where this

Speaker 2: gone. So yeah, so they created this kind of short code they transform when they render it onto the front end. So what we did, we used the ETL as a framework to migrate this data into the vector. So obviously we use the Django RQ as our queuing system. And only one thing we like about this old migration environment, they they had the API ready. So for us to not to write anything on the old system. So now I'm jumping into the Django admin onto the Vactil side. So what we created, we created three kind of uh uh ETL uh model so that holds the old data into

Speaker 2: the system. So this is the Vactel environment, but I'm just jump jump onto the Django admin and if you see one of the item Then it holds the all the API data that we gather from the environment. And one of the challenges we had here is when the two pages are interlinked with each other, then We can't load whole page until the the URL of another page is already created into the site So how we solve the problem is like we created the the two objects of single page. The creating the minimum field of the page that requires to be created so that gives us a slug of the page And then the second ones hold all the data.

Speaker 2: So if you see one of this publication pages here, it only holds like the minimum page field that requires to be created. And also we carry on the old CMS ID as well. So if we need to uh dig up any any page that update like created onto Vectel or not. And then On a content side, it holds all the data that requires. And this is like a transform data. So Vactel knows how to load this jump box and all the other components. So I'm just gonna walk you through as So this is the way we created we have two like English and Irish pastry and then we have a department onto it and then we have a index page of the each type of it

Speaker 2: and if I create like a click one of the consultation here and then it list the the particular type of the consultation and if I click one of these So this holds like uh around 200 as of now 200,000 pages with uh about 130,000 documents. as well as it holds like a currently 300 active user on this side. So we we are proud of this kind of six month project and It it works really and we managed to migrate hundred percent content from old legacy system into the Wagtail without any issue. Like I'm lying without an issue, but we had a challenge that we overcome

Speaker 2: Uh

Speaker 3: good afternoon all. Uh Here I want to uh talk about a bit cross-cultural or multicultural uh team experience. Uh my name is Muhammad. Uh I'm from Tajikistan. It's about uh eight ten hours time difference from there it's fifteen uh thousand kilometers at ten thousand kilometers away and I want to start from my last experience on JengaCon. I nearly had uh to sleep on the street on my first night. That 's uh because of uh cultural uh difference. Uh yeah, uh as I told it's kinda I live in Tajikistan uh and I've worked for US company for the last three and a half years. And for the last two years I'm stepping in on team lead position.

Speaker 3: It's about more about managing teams. And I experienced I found that cultural difference makes sense on a lot. on coding on uh in our job. And we are all good on uh debugging code. Uh how about debugging human communications? Uh let's go a bit deeper. Uh the main problem is the same words, uh make sa make uh maybe different words. Same words, different words. It's kind of the same thing means two different things, meaning on based on your cultural background. One of the my best experience was in my first year. I just said yes, we will handle it on a big uh feature. And yes, it means in our culture it's kind of soft yes.

Speaker 3: I will try my best to do that, but uh it's not a full commit. Uh but my manager uh from US get that yes as a commitment. As a result, we failed the deadline. It was a bit miscommunication, but we learned that cultural uh difference makes sense and a lot. And it's not about being uh wrong or right. It's just about uh different cultural systems that we run. uh that we use a great example it can be this mam that two person can see uh the same thing two differently uh but When you work in cross-cultural teams, uh it's good thing it's gonna in this situation uh Uh two team members should come up uh side by side and this

Speaker 3: look at problem. On that case they can see and understand uh Uh uh themselves and solve real problem. Uh just uh months ago I found a good book about this and I want to give uh Share that one, the main uh ideas from that. Uh the book provides uh hot culture and cold culture kind of patterns uh that surprisingly this is kind of has Correlation with uh climate, hot climate countries and cold climate countries, and hot cultures is kind of they are relationship first, but cold cultures they are task first. Uh in hot culture uh high context they are high contextual. The context makes sense a lot.

Speaker 3: They uh told, speak and read between lines, but uh in cold country culture Uh it's kinda there is no uh context. They're more direct and about the timing, they're all uh hot culture they are flexible in timings, but and cold culture they are precise. And in hot culture, about the yes, there's a term of soft yes, they will try, but it's kind of uh not full commitment. But on cold culture it should be yes or no, it's kind of uh direct. And in hot culture, uh hospitality uh makes sense a lot. It's different, fully different. Uh in hot culture they are by default you are involved. Uh

Speaker 3: Any kind of events are open and group, uh harmony over the uh kind of takes over than results, but in cult cultures they are task-oriented that you need to uh formal limitations on on your kind of meetings. Uh but the most miscommunication it's not a personal, it's count cultural background and but uh both styles are valid, but just we need to make sure that if we are working on multicultural uh teams Uh we are understanding each other. Uh here is a solution to kinda if you are working on that, if you have any problem, it's two simple things. First a confirm confirmation bit bridge. on after the conversation you need to kind of confirm uh kinda rephrase what you understand from uh each other or from the meeting and about time buffering

Speaker 3: that you you should say that you will start a meeting at two Uh and we really start meeting at two uh because hotcast people may come a bit later. And about private first, uh difficult topics should you should say. uh on one-to-ones and then you maybe you can bring to uh group. Uh and overall it's kind of warm and clarity, it's universal communication language. and uh sense kind of cultural bridge it's nice it makes our code better and communication stronger. Uh I will encourage you to try one technique today and see how it's different. uh you can start immediately practicing this. It's kind of uh we debug code together, uh let's debug communication also together, uh make cultural difference. Uh

Speaker 3: Yeah, uh thanks a lot. It was uh some takeaways from uh book Sara Leiner, Foreign to Family. You can go and read it. It's a very small book. I highly recommend to read it after reading this book. Uh my uh Life a bit changed it and now I'm uh communicating with my team uh teammates from US more clearly. I can really understand them. Thank you.

Speaker 4: Hi everyone. My name is Arthur. I'm a PhD student at the University of Chicago in Computer Science, but today I'm going to talk about some of the work. I did with the data transfer initiative. If you've ever run a research study with uh participants who are dane donating their personal data from like online companies like uh Google or YouTube or whatever, and this data can be used for a bunch of different things like uh measuring um addict like addiction to social media just as like one of many many examples. The process is really, really involved. So what you have to do is write like dozens of instructions for these participants. for how to go to the data donation or sorry the data export page of these companies.

Speaker 4: They have to follow these instructions, which usually involves clicking a bunch of different buttons saying like Yes, I want you to include my like maps data. No, I don't want you to include my um like login history information And then finally, they have to export that data into a zip file and then go back to your website, upload that zip file to finally get the data in the hands of the researchers. But even this process of like, you know, waiting to get your expert file could take days, weeks, or almost a month in the worst case. Um So this is not great, and in fact many studies like start and fail because this is such a complicated process. And this is just an example of like how different two different uh portals

Speaker 4: for requesting your data can look So uh what I did this summer with the uh data transfer initiative is we've built a couple of tools to try to address this problem. The one I'm going to talk about today, which kind of includes the other one, is a prototype of what a unified data donation portal for academic researchers could look like. So rather than uh using what I described before, which is really like exercising uh your data subject right of access to access your data. um we're leveraging data portability, which basically enables um uh companies to transfer

Speaker 4: all of your personal data to another entity, in this case like the researchers, with users' authorization. And how do you get this authorization? OWASP 2. 0, pretty straightforward. So we've built uh support for a couple of different or s several different uh services to enable this to happen. Um and we're just using the public APIs of these uh companies. So Here, for example, if I want to, if I'm a research participant and I want to donate my data to understanding online social behaviors , I can start the data donation process, read through um uh a a consent form agreement, accept that, get a little bit of summarization, and then be directed to Tumblr's

Speaker 4: OAuth flow. And once I authorize that data, that can um you know start immediately. It can uh start a week from now and collect data like every week. Uh and um and you know the the possibilities for configuration are kind of uh endless here. But the key thing is that as a researcher participant, I actually don't have to download any of my data in order to donate it to the research studies, which um we hope will be a huge uh like benefit and facilitator for running these types of research studies that require participant data. This is very uh like its early stages, it's it's a prototype we've built, um, and we're really looking for some feedback and um ideas from other people who might be interested. in running these types of studies.

Speaker 4: So please reach out to us. And yeah, and if you just want to talk about data subject rights in general, I'd be happy to discuss that. So thank you.

Speaker 5: Right. Hi everyone. I'm Richard Terry. I'm a Django developer at Lincoln Loop. A big thank you to them for bringing me here again. and for supporting my project Nano Django. I gave a lightning talk about Nano Django last year and I'd like to share some fun things that I've been working on. Since then. So what is Nano Django? Well, it uh it it lets you run full Django in a single file. Um a basic script with a view looks very much like Flask. You decorate your view function with a path and Nano Django takes care of the rest. It has built-in support for Django Ninja, so an API looks a lot like Fast API. But it can also do everything that Django can, including model definitions, which you can then use in views, just like any normal Django project. And it supports Django admin, async views, template tags, and more.

Speaker 5: You can run the development server with Nanajango run, or you can run it with UV, or you can serve it configured ready for production. And it also has a convert command. So once you've outgrown a single file, you can run this to automatically convert your little script into a full big Django project structure. So this is fantastic for learning and experimenting, prototyping, sharing, and building simple sites. So that's where we were last year, and what else can it do now? First of all, uh templates can now be embedded at the bottom of the file, so they're out of the way of your logic, but all still in the one file, which makes sharing your project a lot easier For other app developers, we've now got a plugin system. So if you want to integrate your package with Nano Django somehow, you should find hooks that'll let you do what you want. I've also released another package called Django Style.

Speaker 5: This gives you very simple but tasteful base templates. So we've got a pure CSS version, a bootstrap version. a Tailwind version, and each of those also has an app layout where the body has a fixed height, which makes it great for single-page apps. And these all support menus, forms, mobile layout. The idea is to make it easier for you to build really quick prototypes that look good without needing any boilerplate. This is a standard Django app, so it'll work with any Django project, but it works particularly well with Nano Django because with the new plugin system It'll automatically detect when Django style is installed, and you can just straight up extend its base template I've also released another package called Django NanoPages. This takes a directory of markdown pages, markdown files, and turns them into views with URLs matching your directory structure.

Speaker 5: There are more features I don't have time to talk about, but it's a fantastic way to quickly build areas of static content on your site. Again, this is a standard Django app, so it can be installed in a full project with a couple of lines but it also works really well with nano Django because that'll again detect when it's installed. This time it'll add an app. pages helper to let you uh register the path of the URL. Nano Django and NanoPages both now integrate with Django Distill as well, so you can use all of this as a really minimal static site builder with the power of Django behind it. And that means you can bring in the models and the admin sites so you can add content to a local database and build pages from that next to your markdown content. So now we can make prettier prototypes, embed templates, and easily generate static sites with Django.

Speaker 5: And over the past year, people have told me about some things they've been building with Nano Django , prototypes, microsites, LLM chatbots, all sorts of things. And I thought it would be great to have somewhere to share them. So Nano Django now has a website at nanojango. dev and this has a more detailed introduction as well as documentation and soon some how-tos and links to other videos. people's stuff. But it also has a fun and potentially very useful new feature, the Nano Django Playground. This runs full Django in the browser. You put your code in the editor pane on the left, you click run, and through the magic of Pyodide and far too much JavaScript, your Nano Django site will run and be accessible in the pane on the right. And it supports links, get and post requests, API calls, models, migrations, everything as if you were running it from the shell, but it's entirely in the browser with nothing to install.

Speaker 5: You can also save your scripts and share them with other people. I've got lots of plans for things to add to make this one more useful, so do keep an eye on the blog or on my MasterDone account. I'm really excited about it. I think it has real potential for experimenting and sharing ideas and making tutorials more interactive and making it easier to demo your projects in a safe environment. So I really look forward to seeing what people can build with it I've only been able to scratch the surface in five minutes, but if you'd like to find out more, do come look at the website. It's all on there. Or come find me at the Lincoln Loop booth or at the Sprints. Thank you.

Speaker 6: Hi, I'm Fletcher Heisler. This is Jens Longheimer. We are the CEO and founding CTO of Authentic Security, the company. We wanted to tell you a little bit about the journey from authentic the open source Django project to getting there as one possible path. I've talked to a lot of open source maintainers of various projects here. You know, it's tough relying on just donations to scale up a team in a project, and we wanted to share our story.

Speaker 7: Yeah, so Authentic started in 2018 as a purely open source project, as a side project. Um mainly out of the interest for identity protocols, single sign-on. Um as you might have gathered, authentic is an identity provider. Um basically our tagline is Okta that doesn't suck. Um and just out of interest for identity protocols and A couple of years after that, after enough friends convinced me to finally start talking more about it and start showing more people, I was finally showing it off on Reddit, which I think you can see in here. Actually, no, you can't see in here. It got quite a bit of traction. Quite a few people saw that, which as you can see here also caused the community to grow quite a bit.

Speaker 7: And obviously sharing something that you've built on Reddit and with a potentially larger community is uh not always something easy. Um but in this case it's very much paid off. Um And then you know it kind of got to a point, I think after a year after that read a post , getting an email from uh the CEO of GoodLab being like, hey, we saw your project. Would you be interested in turning this into a company and kind of building something on top of that? Um and then from there we go to a public benefit company. Yeah.

Speaker 6: So I came in just a couple years ago into authentic security, and one of my major roles as CEO was also help us secure more funding before we ran out so that we could scale up a team. We set it up as a public benefit company, which means really whatever you want it to mean, but in our case meant we have a start a charter for a company that says we won't be taking anything out of open source. We won't be putting any constraints on that usage a lot of you know core promises that also limit our options for potential future revenue as a business or acquirers or things like like that, but we felt were the right things to do to show that we are here to support the open source project ongoing. Um we you know were able to raise a seed round based on that plus some uh early enterprise traction. Um

Speaker 6: turned out that was just the beginning uh that that nice Line in the middle is when we uh ended up trending on GitHub uh for a couple weeks. So we're now up to uh over a million installations in the community. A lot of large companies like Cloudflare using us to as their IDP for all of their employees, 911 Center for the state of Washington. So, you know, the the stakes have been raised in terms of if we gotta get things right. Um but so many of these use cases have actually come from people starting in the home lab. Uh maybe have been using us uh as their their home experiment for a few years uh and then deciding, you know, we've had enough with these legacy providers. Maybe we could host something ourselves in our own private cloud

Speaker 6: and and reaching out for enterprise usage as well. So that comes with all sorts of challenges, obviously. We have an open core company. We have free versus paid options. Again, that is limiting us a lot in terms of revenue as a company, but we see that as a growth channel and you know the right thing to do for the project and to be able to support the project over time. What do we decide is free versus paid? That's tougher for some companies and products than others. For us, it's been pretty clear that if this is useful to you as a home lab user, we should give that to you. That means that again we have lots of large companies running us in production for free and we never know about it. That's a cost we're willing to eat. Because on the other side, you know, if you need certain integrations, certain compliance requirements, if you need direct support from our growing team.

Speaker 6: You can talk to the experts and that also becomes a way to generate revenue and a way to feed that back into the project and the company ongoing. That also means we have community versus customers and lots of different channels to manage and lots of priorities to manage. That's more than I can get through in 40 seconds. But we have a Discord, we have a subreddit that we try to keep track of, we have shared Slack channels with some customers, you know, some ongoing communication there. So, you know, it's an ongoing battle of how do you uh make sure that all your customers are happy, that your community is happy, and that you're developing as much of this in the open as possible. So this goes to our site. You can join up with our GitHub project as well. We'll be here for sprints if you'd like to work on integrating your application with Authentic.

Speaker 6: uh or just work on authentic with us, we'll be around. Please check it out. And we'll also have a booth back there. If you want to talk about any of these topics, have any questions, I'd be happy to To talk more, thank you

Speaker 8: All right, hello. I'm Adam Zapletal, Adam Zappl on GitHub. That's my GitHub profile picture in case you've seen it. And I work for Crossway. We're a non-for-profit Bible and Christian book publisher. And if the intersection of those things in Django or Python interests you, come talk to me. We're not hiring right now, but happy to talk. Um And I'm also on the website working group. So that's what I want to talk about. I want to ask you to consider contributing to Djangoproject. com. So if you're not familiar, this is Django's website. But behind it is this repository. So Django's website is open source, if you didn't know that. And you would never believe what framework it's written in.

Speaker 8: So briefly, uh how I started contributing to it. Um So I've done a number of PRs to Django here and there, closed some tickets some tickets, not too many, but um You may know what it's like to contribute to Django. You know, you work hard on a ticket, you uh run the test, commit the code, push the PR up, you know, make the commit message. And then if you're me, you realize you forgot the period at the commit mess at the end of the commit message and you amend your commit and force push. But what do you do after that? You wait. You wait for a review, right? So um for me while I was waiting for reviews, uh, you know, I just decided Uh one

Speaker 8: PR on Django open at a time is enough for me. A non-trivial PR. That's enough Django framework level stuff in my head at one time. So I was poking around the Django organization and found the Django website, started doing contributions here and there, little cleanups, hey, here's a review that needs to happen. Maybe I can do that. You know, eventually get in a rhythm of that. And I feel like, you know, I've found my niche in the Django contributing cycle, which is Something I've wanted. So that can happen to you. So a few specifics on why would you contribute to the website instead of the framework? Well Number one is it's the website. It's not a framework level thing. And that's two different kinds of code, right?

Speaker 8: So if you're a web app developer and you want to contribute to Django, you don't have to just uh learn framework level stuff like the plumbing. Uh there's actual features and bugs that need to be fixed and stuff in the website. So Um it's a different kind of contribution. The PR feedback loop is generally shorter. And it's a mature code base with a lot of people that have worked on it for a long time, very faithfully, some of them I see in front of me. And so the website is not trivial. You probably can assume that, but there's user management, there's um multiple databases to integrate with track, there's uh a stripe integration.

Speaker 8: Did you know that for the fundraising part? So both one-time donations and stripe subscriptions, that's in there all open source. There's the blog and many other things that you can look at and help with. So it's fascinating to me that this stuff is open source. I mean, how many real production, long-running Django websites are open source that you can just look in? look into the code. And I've just put three screenshots of commits or PRs here that I find interesting as a Django developer for my company. So I can go in and look at this discussion around upgrading to Django 5. 2 before I do it at my company and see what was run into, perhaps. Here's the second one,

Speaker 8: a move to the new composite private keys, sorry, composite primary keys feature for the track DB part of the site. And the third is a PR just adding a feature. You can delete your user account now on the website. That's one I got to review personally. So this stuff is here for you to see. So briefly my goals and hopes for the site is one that it's continues to run and be stable and be high quality and all that. But in my opinion, Django's website should be the absolute best shining example of an open source website built-in Django. There should be no better out there. So I think we should work toward that. Hey, maybe it is that right now, but we should continue to do that, work

Speaker 8: on reducing the number of open issues and PRs. And it can be a cool resource beyond the tutorial for people to see a real Django website that they can look into and learn from. And finally, next steps if you're interested in this, just go to the repo, try to set up your environment. via the readme there, there's a Docker way and a non-docker way, and then um learn, figure out the architecture, and then find an issue or PR that no one's working on that maybe you can push forward. And also at the conference, you can find me and we can talk about it. Thank you very much.

Speaker 8: Hello everybody, my name is Megan. If I'm back, that's an Irish name.

Speaker 5: It means I burn in the shade.

Speaker 8: I'm going to talk to you today about what AI tools get right and wrong with Wagtail. Um

Speaker 7: a little bit about Wagtail first. Uh honestly I can't do better than Haim in describing it uh from yesterday's lightning talks. It's beautiful, it's wonderful, it has dark mode. Uh it's a Django-powered CMS. If you're curious, you can go to our docs at talks. wagtail.

Speaker 8: org. A little bit about me, because I think it's important when talking about AI tools to talk about your history as a developer.

Speaker 7: A formal history in programming. It is all very much what I've cobbled together over the years. I am much, very much a generalist instead of a specialist. I have a tendency to kind of learn a lot of things rather quickly and forget them versus learning things very deeply. Wagtail is definitely an exception to that.

Speaker 5: I am also not an AI grump.

Speaker 7: I do think that there are some potentials, potential uses with AI, but I'm also not a huge AI enthusiast either. You're not gonna see me lining up the at the chat GTP store chat GPT store uh when it when the new model comes out or anything like that.

Speaker 8: So I think that's important to know. So

Speaker 5: the project that I did recently that I decided to play around with using Aon on was the Wagtail Space landing page needed to happen. Uh and we decided to extend Wagtail. org so that we could use this uh every year for different events And I decided to test a few different tools during this. I played around with Copilot, with Claude, Chat, GPT. I messed around with Gemini

Speaker 3: a little bit, but I abandoned that one pretty quickly. I think that Copilot was the one I switched off first.

Speaker 7: I just found it really annoying.

Speaker 3: I'm a person

Speaker 7: who uses a specialized keyboard. I need that for accessibility reasons. And the autocomplete when it fills up your entire IDE and you can't make choices about it is just really obnoxious to me. So I went through and saw how these different tools did uh with pretty much some pretty basic wagtail models and blocks. And uh so the things that they did well, um the models were actually very solid. Uh and there were actually things in there that the average developer or somebody who's new to Wagtail might not think to put there that I thought were wonderful. For example, in this code snippet Here

Speaker 5: you'll see that it included help text by default. This is something that developers often forget. You don't always need to use it.

Speaker 7: You know, honestly, it can be a bit repetitive for some of your users. But the fact that most developers tend to forget that option even exists and the AI is reminding them, hey, you can include this here uh is great. I thought that was fantastic. And both Claude and Chat GTP GPT uh were good at doing that. Also as the you know, I kept working on these projects. Uh the AI did get uh very good at picking up on, hey, maybe you want to make this a parent page or a subpage here. Uh it was good at suggesting kind of these features that aren't necessarily shown in our tutorials. And I thought those were really great.

Speaker 8: And I also found it very useful for a lot of non-wagtail things on this project. It was great for front-end code.

Speaker 5: There are probably a few things on our landing page that would make our front-end people like run away in horror. But you know, this is code we're going to be stripping every year, so it doesn't necessarily have to be the best and the greatest

Speaker 7: It was also great for a lot of formatting tasks and organizing tasks, and I also, you know, almost always have an issue with an environment, and it was great for picking up those types of issues. Where AI drop the ball is with templates and template tags. Wagtail and Django are definitely not the same When it comes to how we handle variables in templates. And that's where it becomes very important to know the difference. The example I have here is a for loop that's used for a stream field. We use a value in the variable and AI was not good at remembering to put that in. So it was actually very terrible on the templating side of things, and that is definitely a place I would be careful with.

Speaker 7: Alright, so some final thoughts. In my experience, I am absolutely in love with Claude. That is definitely my favorite out of all the tools that I played around with on this project. I also learned through some folks at this conference that perhaps a agents.

Speaker 5: md file might be something that could uh be a way to solve some of these issues that we're cropping up with Wagtail. I think these tools are great for generalists. It definitely saved me a lot of time. It saved me a lot of having to bug

Speaker 7: people. uh and ask them questions that I thought were kind of low sticks. And when you're working on a project that isn't like for client level work or for something that you know contains like high-level data or security or something like that, these two tools are absolutely wonderful to use. But one thing I will note is Wagtail is a piece of software that works best when empathy and consideration are factor into your development. And ultimately it's something that should always have a human in a loop. Because a robot cannot design an experience for a human being very well at all. And you know, if you're building software for other human beings who have preferences, Who have ways they like to do things. That's ultimately not something that a robot can factor in.

Speaker 7: So definitely consider that

Speaker 5: And I will just leave you with an invitation to join us for Wagtail Space coming up in October. So please come join us and learn more about Wagtail. Thanks everybody. But you didn't understand anything I said, right?

Speaker 8: You can you speak Turkish? No. Can you speak Spanish? Who can speak Spanish? Yeah, nice. Greek? Anyone? Nice. So the problem is that there are lots of people in the world who have some language barriers. Maybe not everybody can speak in English, in Turkish, in the different languages. We most probably cannot speak in every language, but

Speaker 6: can we translate to our software applications to all languages?

Speaker 3: Yes, yes, Claude. So I implemented a simple project Django application which helps you to translate your uh applications to any languages which with help of uh recent LLMs. Let me briefly explain you

Speaker 7: how is a traditional multilanguage app development flow. First, we need to use getText

Speaker 3: in our codebase to define customer-facing parts of the application. translatable. Then we need to define the supported languages in settings that pi. We need to use middleware to get the accept a header from the request so therefore our templates can understand uh who where the user is from and we can set the active language. And the fourth item is we need to get this uh translatable text from Python files to write it to the PO file. And the fifth item is we need to hand over this profile to a translator. Then the translator is gonna use a portal or somewhere somewhere like this. And they're gonna translate this English text or any other

Speaker 3: language text to the target language. Then we need to compile this profile to a mo file and

Speaker 8: Tada, we're gonna have a Turkish speaking uh application.

Speaker 3: But the fifth item is a bit hard. So you need to find a translator, you need to maybe Yeah. You need to you m you might use a couple of portals like TransFax, there are lots of uh alternatives, but it is Super daunting thing. You need to wait maybe for two or three days, therefore you're gonna delay your application release. It is so time consuming, and I would like to target this. Step. And this is an example profile. You can see smaller key key value, you can see message ID, mess message m message string. And I introduced this package which is called YesCoload and it basically introduces a new management command for you, which is Python manage

Speaker 3: translate messages. And it's gonna automatically get your untranslated untranslated profile items, uh profile items in the profile profiles. And it's gonna batch uh into context window size uh requests. So therefore you are not gonna pay a lot of money to LLMs. And the good thing is that it actually uses a light LLM package under the hood. So therefore you can use any LLM. So if you like OpenAI, if you like cloud, if you like anything It's it's any LLM. It's it it has a support more than hundred

Speaker 8: LLMs. And this is the result. For example, it won it automatically translated tr to to Greek language. So therefore, I would like to uh suggest alternative way to fifth item and using a uh a solution which serves from our terminal, which is managed by transit messages Half the install, we just install from the pip, we just add it to the

Speaker 3: installed apps, and we just need to define the the LLM model we would like to use and the API key. And if you like to uh give more context to the LLM, you can provide a context related to your application. For example, I added football-related content in here. So if you like to Said don't translate off site, don't translate goal. You can also define these type of things. And it's free to use and free to contribute.

Speaker 2: If you like to contribute to the project, you can also Check the issues. I would like to add support for Django model translations too. So therefore we can also maybe translate dynamic content. And it's here. Please feel free to check the library, give feedback to me. And that's all.