One, two, there we go. Right, so this is about something I was thinking up on the plane ride from PyCon Australia to here,

which was last week. I like content in text files, it's great. You can have things formatted nicely, they can be in Git, you can do pull requests on them, it's all fantastic. But I also like things in CMSs. In particular, I'm a big fan of Wagtail. And so I'm redoing my personal site in Wagtail and I'm, well, I mostly like it, but there is content I want to have in static files.

I have things like lists of national parks and lists of my talks that don't really change, they're append-only, they're more suited to Git. And so I thought, why not have both? How can I combine these two into one site? In particular, I didn't want to have to rewrite a custom thing that parsed YAML files for every page, so it was really slow.

I wanted to use the ORM in Django, because it's great, because it's Django. And so I have made a thing called, I haven't pronounced this yet on stage, let's go with YAM-dle, which is an ORM for accessing data in text files. So in particular, it lets you have structures like this, where you have files in a tree under different model names. So here, for example, I have all my talks

from this year in one YAML file. They look a little bit like this, sort of nicely formatted, you can go through. I can do edits on these easily on the plane. And then what it lets you do is use the Django ORM to query them like this. So you can say, oh, I actually just want to talk to these normally, like normal Django models, and do sorting and filtering and even gets and stuff like that.

So how does it work? Well, it's kind of really simple and awful, simultaneously. So what you do is it reads the YAML files that you saw previously into memory, sort of like normal Django fixtures. It then makes an in-memory SQLite database. It then uses Django's internal migrations code to make tables in that database.

It then writes the models into that database and saves them, and then it then routes queries for them using a database router to that database, all on every startup of your piece of software, because that's a great idea. So, in particular, a couple of things. It is just the normal YAML. Django's load data, which does fixtures, is very similar. If you look inside load data, it's just kind of reading YAML and JSON

and just does make a model instance, model.save, make another one, .save, that's all this does too. Obviously, YAML, if you don't know this, you safe load, because normal load can do code execution, very bad. I use the schema editor for the database. It's this amazing piece of software written by some guy, I'm sure you all know. But what it lets you do is you can take

just the bit that makes tables and say, hey, I want to parse this model and make a table for it, outside of migrations. It's kind of a simple way of doing it. It's like three lines. So if you're curious, just an interesting thing to look at. And it also uses a thing in Python 3.4, which is new, which is SQLite's database memory URIs. So SQLite used to have a thing called colon memory colon,

which is just, hey, I want an in-memory database, and it was thread local, and every connection was a brand new one. You couldn't share it very easily. SQLite's come along since then. It lets you do shared databases like, this is shared across all my threads. It has caching and local stuff in it. And unfortunately, you need URIs to do this, and Python 3.4 is the first version

that supports SQLite URIs. So it's not great, but hey, there you go. And so the result is I have my website redesign almost done. Pages like this are powered entirely off of this fake YAML-based RM. It's pretty great. You can just go in there and say, hey, I want to have all the places grouped by the different section and ordered by name.

It just works, and I can edit these in my Git repository very easily. If you want to go and download it, it's on GitHub right now. I pushed it up about 10 minutes ago. It has a readme, it has some documentation. I don't promise it'll work, but it works for me. Standard disclaimer. And then finally, one last plug. I and some other people are helping run a community conference in the North Bay,

in the Bay area called North Bay Python. If you are curious, please come and talk to me or follow us on Twitter or go to website. We have a CFP going up soon. Thank you very much. So I have a mild content warning here. I've tried to make sure there's nothing too horrible in here, but if you are squeamish,

there will be artificial eyes in this presentation in large numbers. But yeah, so just over a year ago, my wife and I were involved in a pretty nasty car accident over in Yellowstone Park, and I ended up down one eye, which sucks, you know, but I did get to learn what it takes

to get a new one made. So I'm now, you can come and see me in the corridor later and see if you can tell which of my eyes actually you'll know because I'm about to show you. One of my eyes is no longer real. It's an artificial eye, and I'm going to talk about what it takes to make one of those because an unexpected highlight of this otherwise pretty awful experience is I got to learn all about eye making.

So if you need a new eye made, and I have got a very good recommendation, so talk to me if you need a lead. The first thing you have to do is pick your eye maker, and eye makers are called ocularists. There are about 300 of them in the United States. It's a very niche profession, and it turns out there's not an enormous amount of demand for this, but just enough demand

to keep a professional association going. And fascinating, this is a family profession. If you want to make eyes, there aren't that many places to learn to do it. You basically have to apprentice with someone, and it turns out that ocularists are almost all related to each other, and they have these apprenticeship family relationships. And I think it's a fascinating thing

because it's both an art, a craft, and medicine all rolled into one. So I talked to four ocularists in the San Francisco Bay area, which is basically all of them, because why would you miss out on an excuse to meet people who make eyes? And one of the things I showed them, obviously, was show me what you got, show me your eyes. So these are some of the eyes that I was shown

by various ocularists that I didn't pick. And then I met this guy who had this beautiful box of eyes. This is the guy I ended up picking. These are the eyes that he showed me. This is a collection of blue eyes. He has a separate box for all of the brown eyes. And his name's William Danz. He's been doing this for 45 years, and he is a fifth-generation ocularist.

His grandfather, his great-grandfather, all the way back to like, I think the 18th century in Germany, his family had been making eyes, originally out of glass, and these days out of acrylic plastic and oil paints. And his son is apprenticing under him, so I got to meet his son, who will be a sixth-generation ocularist as well. So it turns out it's a three-day process, essentially.

You go in for three consecutive days, because all of these things that are made custom to fit you, they have to match up to your other eye, because otherwise it's gonna look a bit weird. So day one is the mold. I decided to cut the photograph of this, because this is probably the most distressing part of it all, but essentially this is the same stuff they use for taking dental impressions,

and they sort of squirt it in, get a mold of the gap that the artificial eye is going into, and take that away and use that to create the eye. Day two is where it gets really fun, because that's the fitting. So he's got a mold, he makes the eye out of acrylic plastic, just the shape, but he needs to figure out where the pupil is going to go.

And so he draws it on with a felt-tip pen. This is my actual eye, but at an earlier stage, when he was still trying to work out where things going. And then I have a video, which if you're squeamish, you might want to look away, but I don't think it's too bad. Is that animating? There we go, yeah. So he pops it in, and uses that to make sure

that he's getting it in the right place. Then based on that, the exciting day is day three. Day three is the painting. And you'd expect that painting an eye would be done mainly from photographs, but that doesn't work, because a photo might not have the exact colors that are going to match your real eye. So you have to go in, and actually sit for the painting.

So here he is, holding up this eye that he's been working on, comparing it to my real eye, and making adjustments, and just making sure that he gets that painting exactly right. And because we express great enthusiasm at learning more, he took us back into his laboratory, and showed us where the magic happens. This is straight, it's just regular oil paints on plastic.

That right there is the eye mold. So this is the mold that he made from that impression, and that's my eye in the process of being painted. And the veins on it are pieces of red silk thread, because this is the best possible, he found this is the best way to get the illusion of veins,

is to tear the threads apart, and then tweezer them on. So you add all of that together. This is a video of the moment that I got my new eye. So in it goes, and there it is. The reason it can move, is I've got a permanent implant in the socket that's wired into the muscles,

and then the artificial eye just sits on top of that. So I've actually got quite a good amount of movement from it. And this is the finished eye, and that's how you make an eye. Come and ask me questions later if you want to know more. Thank you. I'm Katie, my Twitter handle is hidden somewhere on this slide

if you want to live tweet about my talk. So, hi. I've been thinking, I don't speak your language. I don't speak American. What I speak is Aussie. G'day. Australian is not American.

There are some slight differences. This is how I spell color. This is how I spell center. This makes CSS really fun. This is how I spell localization. And I like to be able to use languages,

programs, computers, applications in my own language. So localization is important. So I've been thinking, there's this Django thing, you may have heard of it. There's this wonderful welcome page, and you get an administration area, and if you speak American you can read this. But what about everyone else?

So, by default, you get American. There is a partial translation for Australian. However, I don't only speak Australian. I speak emoji. So today I am announcing this translation. I have translated the entire Django 1.11 framework

into emoji. You're welcome. This is the Hello World app. I specifically chose not to translate the Python into emoji because that wouldn't actually work. This is the main site admin page.

So you've got Django admin, site admin, and then you've got your groups and your users, and you can go in and you can add new users. You cannot add a user that is just an emoji character, sadly, but you can edit users and it's all there. And that's really great because it's really hard to try to translate hashing algorithms into just emoji.

You can also add your passwords and all that, but the wonderful little listing of what you have to do for your passwords, I did translate that exactly. So for those playing at home, your password cannot be too similar to any other personal information. Your password must contain at least eight characters or your custom setting.

Your password cannot be a commonly used password, and your password cannot be entirely numeric. That's great. And if you notice very closely, there is still some English American in there. These are strings that, as far as I can tell, you can't actually translate, and they stick out really badly.

And you can create groups that are single emoji. So there is a group in this particular setup that is just a unicorn emoji. And then you can delete your groups again and stuff. So that is EMJI, a new translation. I had this all up on my GitHub under the repo Millennial.

You're welcome. Django has a bunch of actual languages that people actually fluently speak. We have Welsh. We also have a whole bunch of other translations, but there are so many, so many, so many incomplete translations that if you happen to speak any of these languages, please help out.

It would be really great. There is this one that is partial, and does anyone know what this particular code is? Yell it out. It's Klingon. There is a partial translation already there. This is not me, I swear, of the Django admin already in Klingon. Yeah. And that is an actual real emoji as well.

But if you are seriously interested in translating and know any language other than American, go into the documentation. It's really great. It's really easy to sign up to the translation service, and please help out, because it'd be really great if other people can use Django in your language. Thanks.

Good afternoon, class. I'm Dr. Russell Keith-McGee. This is Emoji Archaeology 101. If you're looking for Dr. Bennett's class on making the most of your Django Illuminati membership, it's just down the hall. In 1963, the Human Emotion of Happiness was created. It was created by the American Harvey Ross Ball, who was employed to create an image of a happy face

to raise the morale of employees at an insurance company. But once people realized that it was possible to express emotions, they wanted to express emotions of their own. In a New York Times interview in April 1969, Vladimir Nabokov said, I often think there should exist a special typographical sign for a smile,

some kind of concave mark, a supine round bracket. And then in 1982, Scott Farman had a breakthrough when he proposed the composition of three ASCII characters as a trigraph to express an emotion, happiness. Although these code points don't, in themselves, represent any emotional context, if composed horizontally, they combine to provide a powerful expression

which the user can comprehend simply by turning one's head 90 degrees to the left. While happiness does have significant utility as an emotion, users felt it was not meeting all of their needs. However, by replacing the third code point, the much more functional emotion of unhappiness could be expressed. This ironically led to much higher levels of happiness because users were now able to voice displeasure

at everyone that disagreed with them. Thus began a pre-Cambrian explosion in the expression of emotion as users realized the hidden potential of the US ASCII code point set. The first changes were simple issues of ergonomics. By reversing the code point order, it was possible to evenly spread the physical exertion required to express emotion.

More sophisticated extensions were then added, such as adornments, wearing glasses, and optical tiredness from staring deep into the ASCII code chart looking for emotional inspiration. There was also a move to represent more extreme emotions, such as extreme happiness. Some expressions of extremists couldn't be embedded in a simple three glyph. They required the introduction of a fourth glyph

to demonstrate scorn or to embody a simple tear rolling down the face. Some purists felt that the three code point limit should be retained, and so they compressed complex emotions, losing the fidelity of nasal expression. Others freed themselves of NRE constraints, allowing for the rendition of, say, the absurdist philosopher Homer Simpson

or beneficent midwinter courier Santa Claus. Others revisited the premise that emoticons had to be expressed horizontally and looked to the perpendicular as a presentation style. However, the U.S. ASCII code set was reaching its limit at this point. This led to the introduction of Unicode providing vastly more alternatives with which to construct even deeper expressions of emotion.

It's not clear from the literature that any of these glyphs are actually used in their linked languages of origin. The schism between minimalists and maximalists in the expression of emotion reached its zenith in this pair of expressions, the leaven character table flip as the ultimate expression of anger, and a single katakana character

as an expression of simple happiness. Unfortunately, pressure was placed upon the Unicode consortium to allow more literal expressions of emotion. This started with simple renditions, but over time these expressions became more and more literal, removing all subtlety and nuance, and indeed beauty from the process of emotional expression, perhaps best demonstrated by the introduction

of the pile of poo symbol, allowing scatological references without the need to know what scatological means. This has been accompanied by a loss of agency. In the past, users could simply disruptively innovate and develop their own emotions, but like some sort of big brother, only those emotions approved by the Unicode consortium may be expressed. It doesn't matter if you like banana splits,

the consortium, the savage arbiter of the Sapir-Wolf hypothesis has determined that you shall not express those ideas, and no longer may we compose those symbols to create rich new emotions, only those compositions approved by the consortium are permitted. The modern emoji represents a significant loss of our collective culture, the ability to embody happiness in the eight bits of storage necessary

to display a right bracket. This, this is the essence of the human condition. This is who we are. We are not stardust, we are not the champions, we are not a number, we are emotions trapped in a brittle corporeal manifestation. So what are we to do? Some might call for emoji to be eliminated, to be struck from our collective history, but that is defeat. We should fight for our emotions.

So rise up, rise up my children, smash the control image, smash the control emoji, smash the control machine, we have nothing to lose but our chains. Do not be constrained by the limits placed upon you by the consortium. Compose new emotions and express them, express them deeply and longingly and outwardly. And before someone asks, yes, this will be on the exam.

I'm not getting my notes, so let's wing this. Okay, so, hi, my name's Andrew Pinkham, and I'm here to talk to you about the improved user. So Django has an existing user model. It gives you all of these. The problem is this isn't necessarily what you want out of your user model.

So this made a lot of sense when it was shipped, but nowadays you just wanna log in with an email, you want a password, and for international reasons, you usually don't want a first name and a last name. That doesn't work in a whole lot of countries. So you might think about a short name or a full name, maybe. So if you've read my book, Django Unleashed,

you know that I sort of go through and I talk about how to build this. And as a consultant at Jambon Software, I was taking that code and just copying and pasting it. When working with Russ, Russ pointed out that this was really, really, really, really dumb. This is what he looked like when he told me this.

This is unedited. And so we went ahead and we created a reusable app called Django Improved User. It's fairly creative. So Django Improved User goes ahead and it just does email authentication, it gives you a password, there's a full name and a short name,

and you can compose all of these if you would like to go ahead and do that. And it includes all the stuff that you need to sort of get the ball rolling. Forms, admin, if you're using the factory boy, we have a test factory for you. And all of this is tested in Django 1.8, 1.10, 1.11. So if you're starting a new Django project,

we hope that you find this really, really useful. A quick note is that right now, the version on PyPy is actually version 0.3. Version 0.4 is going to be shipped out very, very soon. Does this mean that it's really in beta? No, we're using this in production in like four or five places. The only thing that we're waiting for

for version one is improved documentation. I'm working on it. I would love some feedback. If people have done a lot with user models, I would love to hear, like, are we helping here? Are there any changes that we could make to sort of do that? And on the documentation side, if anyone feels like writing documentation,

that sort of thing, we would love some help. So thank you very much. Thank you, Andrew. Yeah, so what I want to talk about is the fact that the cloud isn't 100% available. All the services that we can use that make our lives easier can and will go down. And the time that that happens is not the time to fix it.

You don't really want to be live coding while your payment processor is down to make sure that your site doesn't blow up. And so we had a client, and we had done an MVP on a store, launched it, everything was great, payment processor went down. And so that was when we started to get

a flood of 500 emails from places that we hadn't quite planned for this. And what that did is it meant, all right, it's time to buckle down, it's time to harden the application and make that work better. So I just want to give you some of my inspiration, some of the things that I've learned so that you can do this. It's actually not as hard as I thought it would be.

So the first thing to do is actually more of a business decision than a technology decision, and that's to think about all the different touch points that you have to outside vendors and think about what you want to do if they fail. If your credit card processor is down, do you want to store information and do authorizations later?

Do you want to hard fail? Probably not the greatest idea, but it's a valid way. And yeah, so same thing with sales tax. You may use a vendor to tell you that. Are you going to email every customer that made a transaction and say, we're actually gonna charge you this much more because our sales tax vendor was down.

Transactional alerting, anything else in the cloud. You're basically gonna go through and figure out what do we want to do. With that in mind, you can tune and say, hey, are we gonna display a 500? Are we gonna have a generic message that pops up

and says, we couldn't get to a vendor? Or are you just gonna adjust the messaging for each instance so that it doesn't say, this terrible thing happened when all it was is you couldn't send them an email that their order had gone through. There are multiple levels of failure in the application ranging all the way from lack of data link,

just unplug the network cable, DNS resolution. I keep records in my router at home so that I can override various vendors and say, you go to 127.0.0.1. But then the rest, we need software. And so we can do timeouts, connections refused, and anything other than the HTTP response

that it would suspect. So, depending on your vendors, this will be either really easy or not so easy. Braintree is actually kind of nice. They give you the ability to do Braintree environments. And so you can set up this, use Braintree configuration configure,

and now I'm pointing Braintree to a local server that I just set up a URL that matches what they would be calling return HTTP OK. We'll go into more detail. One call out, unless you're running a local proxy with SSL, you're probably gonna have to find

some way to turn off SSL because your payment processor wants you to use that. If it's not configurable, like Stripe, who just hard codes their API strings in their init module, you can always monkey patch, override at runtime. This is not something we're putting into production,

it's just something we're using to test production. If it's SOAP, it gets even more challenging because SOAP has WSDLs, and WSDLs connect to different URLs for different endpoints. The way that I've found best to do that is I download the WSDL, save it as a template,

and then build a view that renders that with URLs. This is the view that I use in order to do that, and so I'm able to use the same view for the WSDL and the option. You can see there's a 50 second timeout there, that's usually enough, you may have to tweak it depending on what the vendors module is set to wait for,

and then it just ends. You can also return weird status codes. I just usually leave a bunch of them commented and I'm like, well, I wanna time this one out, oh, I wanna do bad request, and go from there. And then use your unit tests, Selenium Suites if you've got them, Spyder, just set something loose that follows all the links on your site.

And then lastly, test as a user. Do what they would be doing, and see what they're seeing. And then retest often. Huh? Yeah? Oh, I thought you were coming up to, okay. Hi, I'm Josh. Does anyone here use Django Storages? Pretty popular.

Yeah, and if anyone uses the Django Storages Redux, please upgrade because I don't maintain that one anymore. We've become Django Storages. Cool. So yeah, I'm here to talk to you about the Django Storages library, which is I think the most popular library for plugging into the, you know, you wanna host your files on S3, you wanna host your files on Azure, Google, Cloud, whatever, not the most interesting library, but necessary.

So I wanna talk about past, present, and future. So Django Storages is a super old project. It's actually pre 1.0. I think Django 1.0 is when the storage API shipped, and it basically hasn't changed modulo some minor max length features and such since then.

And this project came out, you know, I guess the guy who wrote it, David Larlet, wrote it, saw what 1.0 was gonna look like, and released it with S3 starting, followed by a bunch of other ones that have since been removed, like Mogile. Anyway, it was pretty much abandoned in 2014,

which is when I was working on a project that was heavily international, so we decided to do Python 3, which is also when I think Python 3 became obvious it was gonna win. There was like a lot of talk about Python 2.8 and stuff like that until Guido at one of the PyCons was like, nope, not happening, sorry. So I, you know, shipping a Django site,

every project was upgraded to Python 3 except this one, so I forked it, commented on all the Bitbucket things, like hey, locate my fork, come use it. And as Django storage is Redux, and about a year and a bit later I became the official successor, Django Storages, so that's where we are today.

And we're shipping nine backends, code quality and how much each of them are used across, I'd say varies, certainly the S3 ones are heavily used, and there's also a lot of demand for Google Cloud, which was added because Google's been pushing that out of Azure, Dropbox. Man, this is my first time maintaining anything,

no one ever told me, it's a complete pain. It's really, especially because I didn't write the software, you know, I'm dealing with, oh man. So I work on it as I have time and motivation, finally got in the Google Cloud backend, took a while to get bozo three and two, but that's what it is, it is what it is,

so I have like a roadmap of this that I'm hoping to go forward with, here's some ideas, I see I'm about halfway through. So right now the test suite uses mock, which is awesome and is a great idea if you're making web calls, if your whole library is wrapping web stuff

like cloud things, I think this is a terrible idea, like I ship a ton of, not a ton, because I don't ship a lot, but there have been regressions because we mock out the connection call and then the connection doesn't get called, and that's basically what the point of the library is, so the test suite I think should be done live.

I'm a big believer in the UNIX philosophy, I mean, I use Vim for Christ's sake, and this obviously, this library completely breaks that, Azure is mixed in with bozo, and I've never needed Azure, but I use bozo all the time, but I actually think this makes sense in this case, it's not a completely,

I don't think it's a very hard problem, there's just an API, but there's a ton of different service providers and there's a lot of commonality if you're a one cloud provider to a next, so I think it makes a lot of sense. It's also a lot of legacy stuff, there's this AWS preload metadata setting, which every time we break, the same person comes around three months later being like, hey, this is broken,

I'll be like, oh, sorry about that. So I don't even think we really need that, so I've been thinking a lot, like, what can I do with this, because I get a ton of emails about it, a lot of stress, because I'm not responding to the emails about it, and so what I'd like to do is fix this once and for all for everyone, and then maybe submit to jazz band, which if you guys don't know,

is sort of like an Aegis project for Django projects that are popular in the community, stable, and are maintained by a group. I mean, I sort of remember the Python standard libraries where libraries go to die, but if it works, then it's good enough. So I need some help.

You, I freelance full-time, I do not have the one month of work it would take for me to fix this by myself, so if your company wants to donate time or money, or you're interested in sprinting on it, people, lots of people have emailed me, they join as co-maintainers, they merge in their pet feature, I never see them again, so I've listed out some major projects,

and I'm giving a talk on this and other stuff tomorrow, so hope to see you there, thanks. Thank you. All right, so I'm gonna do a lightning talk related to K-pop and programming. So do we have any Korean speakers in the room?

Yes, no, yes? Any Chinese speakers? Mandarin Chinese speakers? One, okay. So I'll go into the Slack, let me start my timer. Again, being fair. All right, so I'll go into the Slack, the DjangoCon Slack, and I'll post two videos a little later from YouTube.

This is a video by a group called Exo, specifically Exok, and this is the Korean version, and so this group performs in Korean and in Mandarin, so hence Exok and Exom. The way this, and you're thinking, well, okay, that's exciting, Kojo. No, you're not, really. But you're wondering probably,

well, how does this relate to programming? One of the things as developers that we often hear about programmers who are being hired is that people are looking for rock stars, and a rock star programmer, when we think of a rock star, we tend to think of someone who is a high-performing individual, may or may not work well with a team. Now, if you've actually done any sort of professional software development,

or if you just contributed to any sort of an open-source project, you recognize that software is built in teams. There's not just the lone genius who goes off onto a mountaintop and then writes the wicked codes, and then we all use it, and it's wonderful. It's usually software is built by teams, and so if you are looking at hiring,

I'm gonna mute that, there we go. Oh, that doesn't work, okay. If you're looking at hiring people to build software for you, you want someone who's gonna be a better team player, and so as opposed to a rock star, what you want is you want a K-pop idol, and so the question there is why. K-pop idols are generally very well-trained,

but as you can see here, they function very well as teams, and this is really one of the defining aspects of K-pop idols, and so it's a little bit humorous, but it's also a billion dollars worth of true. There are at least two billion dollar publicly traded companies who are built

around the K-pop industry. This group performing here, EXO, they're currently the flagship male group for a company called SM Entertainment, which is valued at over a billion dollars in the Korean stock market. So what are some of the defining characteristics of the K-pop idols? One, everyone has a specific defined role, so you have vocalists, you have dancers,

you have rappers, and then you also have visuals who are trained in acting, and those are the people who show up in television shows, things of that nature. So everyone has a clear role, and they know what they're going to do, but even more important than that, and it's something that I think is missing in the American programming industry, is the aspect of training.

So most of these gentlemen you see here have been trainees. These guys are in their early to mid-20s now. Many of them have been trainees since they were 12, 13, 14 years old. And so they have been trained to be these vocals, these rappers, these dancers. If you're looking to bring in quality people to help you build quality software,

your organization needs to have some sort of way to bring people in and then help them become the DevOps people, the backend developers, the frontend developers you want them to be. And so you need to take more of a K-pop idol approach to bringing in people and training them to do, to perform the functions you need them to perform for your organization to succeed, instead of hoping you'll just go get a random rock star

who will show up and do his rock star magic and fix everything. So I'll put links to these two videos, one in Chinese, one in Korean, in the DjangoCon Slack, but that's just a little something for you to think about. There, there's a lightning talk. Not spectacular, but if I can do it, you can do it too. So keep that in mind, maybe here, maybe at your next local meetup.

And with that, we will adjourn and head to lunch. Everyone enjoy, and we will see you tomorrow.