Actually, before I introduce myself, I would like to say thank you very much to the organizers of this first pylon dynion for the huge effort they've put in. It's quite a big job to do the first edition of a conference, and they've pulled it off with a lot of aplomb. And I know they've mentioned about the little crises, but probably most people haven't even noticed those little crises unfolding because they've been dealt with beautifully. So thank you very much to all the organizers. And of course, thank you to Bloomberg for hosting this and their sponsorship of the conference of Python in general. It's valuable. It's needed. It's really important. And I think that I can speak for everyone to say that we're grateful for it. I should also say, I don't know who the individual was who signed off on agreeing to have a Python conference here in the Bloomberg headquarters, but thank you to them as well to make sure that they hear that. And finally, thank you for inviting people. That's honestly a big honor to be invited to speak to you. So that's me. That's what I look like on television. And I don't tire of pointing this out, but it says, I'm Python software. And my name is Daniela Prochita, by the way. I work for Divio, divio.com. We're a Python Django company. We provide cloud hosting for Django.  We use Docker and Django and all those things. Come and talk to me about that afterwards, because I'll be very happy to talk to you about that. I'm involved in Django itself. I'm on the core team of the Django project. And I'm vice president of the Django Software Foundation. And I'm sad to say it's probably not as glamorous as you might imagine. Another thing that I'm involved in a great deal is the Python in Africa movement. And Naomi mentioned that this morning in her keynote. So particularly in Pycon Namibia, which has been running since 2015. Those are some of my friends from Pycon Namibia. And since then, we've had Pycons in Zimbabwe in Nigeria. And now in this year, I'll be going to Pycon Ghana for the first time. And there are plans afoot for a Pan-African Pycon, too. And it's not just people like me going to Africa or events happening in Africa. African Pythonistas are becoming more and more involved in our community. So the Django Software Foundation and the Python Software Foundation both have African women on their boards just in the last year or so. I think that's really something. And the last thing I want to mention is I'm one of the organizers of Pycon UK. So if you're not tired of conferences, and I hope you won't be after just a weekend of this one, there's another one in Cardiff in September 15th to the 19th. Our call for proposals is still open for another six days. So I've mentioned that to most people I've spoken to already. But the rest of you, please go and have a look at our website. Think about coming to Cardiff. It's a very nice conference. If you've enjoyed this one, I'm sure you'll enjoy that, too. And finally, if you need my contact details, there they are. But the best thing is just come and talk to me now that you know what I look like, you'll find me easily. So let's get to work because I want to talk about the naive programmer. And I mean the naive programmer. I don't mean the bad programmer or the ineffective programmer or the programmer that you don't want to have on your team. I just mean the unsophisticated programmer. And nobody is born sophisticated.  And the naive programmer is absolutely everywhere because every programmer starts out being naive. And I'm a pretty naive programmer myself. So in some respects, I'm quite sophisticated. I know to spell naive with two dots on the I. And also that they're called a diuresis. So I imagine I'm quite sophisticated. But as a programmer, maybe not so much. So here's the naive programmer. Keep in mind that I'm self-taught. So my code may be a little messy. I know programmers love XKCD. So this is an XKCD cartoon for almost every conference talk. So here's the naive programmer engaging in an encounter with someone else. We'll come back to this in a minute. Now, to understand sophistication and naivety and programming, we have to understand programming as a craft. And programming is a craft, or an art, or a skill. And I will use those three words completely interchangeably. And we need to understand some of the characteristics of arts or crafts in order to understand programming. Therefore, obviously, everybody would like to be better. Oh my goodness, I can just see that I changed a word and forgot to change the other word. Well, how embarrassing.  Everybody would like to be better at their craft. So failure of quality control. And it doesn't matter. Let's skip that. I have to leave it there for a minute. I'm embarrassing.  As much as the most naive and inexpert craftsperson wants to be. Now, of course, thank god I got rid of that, there are completely different kinds of arts or crafts. There are aesthetic arts which are measured against human judgment. So you have critics who will measure your work. And fine art, or poetry, or music. And in these arts, you can engage in a dialogue with your critics. And you might be right, and your critics might be wrong. Maybe they just haven't caught up with what you've come up with yet. But in practical arts, your critic is the world. And you don't get to argue with the world if the bridge falls down. It's not a critic that has a say whether your work was a success.  And if you're a programmer, then you'll find that the Python interpreter is a very harsh critic. And you can't argue with it, or plead, or threaten, or any of those things. Or tears, I've tried all those things. Here's another difference between arts. Some arts are repeatable, like the business of landing an aircraft.   But some arts are creative, like painting or musical photography. And this is really important because in these arts, when we create a new program or a painting, we're creating something that didn't exist before. We start with a blank page. So some are creative, and some are repeatable. And if you go into the theater to see an avant-garde improvisation, that might be quite nice. But if you go into the operating theater and find out that it's going to be an avant-garde improvisation, you'll think maybe that you'll go to a different theater instead. So anyway, programming is one of those creative crafts, or arts, or whatever you want to call it. And this means that even though programmers are not painters, or photographers, or musicians, that in one respect, they're doing the same thing as other artists. And that is that they are practicing a creative skill. And we'll talk a little bit more about these people shortly. Does anybody know who they are? Does anybody recognize any of them? Naomi, it's true. They are too young, I think. So I'm also older than you think. So all bold men look the same age, I think, or something. Anyway, we shouldn't talk about artists just being worse or better, as though they were somewhere on a one-dimensional line, because that's very reductive. It's not a good picture of artistic prowess. All kinds of things matter in art or craft, technique, creativity, judgment, and sophistication. And they're part of what it is to be a complete artist. You are not a complete artist if you lack in any of one of these qualities. So the artist who lacks technique, we call inept. The artist who lacks creativity is dull. The one who lacks judgment is uncritical. And the one who lacks sophistication is naive. And to be sophisticated means to be educated.  I just mean that you have been brought along in a culture and versed in its traditions, able to understand and meet its standards. And you can't become sophisticated on your own. You can only become sophisticated through education in a culture. So the sophisticated artist is in a kind of dialogue with their own art, with the practices and the theories and the history and the traditions of their art. And let's meet a sophisticated artist to understand this better. This is Georges Brach. He's one of the giants of Western art. He exemplifies every kind of artistic excellence, the epitome of artistic sophistication. He was a sculptor and a collagist and turned his hand to all kinds of things. Above all, he's known as a painter of exceptional ability and achievement. And even as a very young man, he had an obvious talent. But then his, sorry, even as a young boy, I meant to say, because as a young man in his 20s, he had a couple of encounters, first with the phovists and then with Paul Cezanne. And those encounters turned him into a world-changing painter. Paul Cezanne pursued innovations in form and structure and perspective. And he raised all kinds of questions about them. And he ignited a revolution because Georges Brach, together with Picasso, tried to answer those questions. And together they invented cubism, which is probably the most single, most significant development in art in the 20th century. And cubism is not just a style or way of painting. It was a deeply intellectual, theoretical struggle with questions about reality and its representation. It represents an engagement that reaches across multiple dimensions, back in time to argue with the history of painting across the arts to engage with developments in fiction and poetry and music or across cultures to Eastern or African art. And it also draws in scientific and mathematical discoveries or new political ideas or technological developments and philosophical arguments. It was all-encompassing, and it drew things in from every possible angle. Brach was an artist genuinely in total command of his craft. He was able to pull everything together in layer upon layer of intelligence and meaning and then speak back to the world through his art. And he brought something so compelling to his dialogue with his discipline that it could never be the same again. So he's an example of sophistication at the highest possible level of this matchless artistic intelligence. And it's key to what allows us to call Brach a complete artist.  He's just a good example, and I like his pictures.  The important thing is you need one of the things that Brach has, which is the ability to address your craft with sophistication. Now, painting isn't programming, but sophistication applies to programming in just the same way. It's an essential dimension of the mastery of the craft. And there are programmers who have this mastery of their craft, as well as they have technical and creative and critical faculties, but they also have an ability to think richly and deeply and broadly about what it is they're doing in programming and faced with any programming challenge. They can draw upon resources that come from every direction. They're versatile and powerful. They see parallels and connections, and they can relationships and tensions that less sophisticated programmers would have no access to. They work with concepts and ideas, some of which come from other disciplines, that allow them to describe and conceptualize their problem field in a way that simply wouldn't be possible for others. So the sophisticated programmer draws from a deeper well. And that's the programmer that we want to be in possession not just of technical or creative or critical strengths, but also this intellectual depth, educated sophistication. It's one of the powers of the artist. On the other hand, just as the sophisticated artist can help us understand what it is to be a sophisticated programmer, I think that the naive artist can help us understand what it is to be a naive programmer. So let's meet a naive artist. Here's the first person I showed.  He was the quintessential naive artist. As far as I know, he was the artist for whom the term naive art was invented. He had no education in art. And if he had influences, they were probably found on packets of sardines or something like that or children's books. This is not somebody of the stature of Georges Braque that we're talking about. His work was coarse and buffoonish. And he painted in this flat primitive style with a child's, I don't think I can better be that near to that thing, actually. He painted in this flat style with a child's grasp of perspective and anatomy. If you had an art teacher in high school, your art teacher probably had a better understanding of art than Onri Rousseau and probably had fewer limitations, too. He became a legend. His understanding of color, for example, so lacking that according to the legend anyway, he would go into art shops asking for tubes of paint, the right color for painting nudes. So he was a painter of immense deficits. I mean, the main problem here is not a lack of sophistication but an excess of hideousness, I think, actually. But some of his paintings are actually quite charming, like this one. Still, no grasp whatsoever of things like anatomy or how bodies can be drawn, but there's some charm in there. Some critics felt that Rousseau was so oblivious to anything in arts and that his work was so devoid of thought or direction or intention that they couldn't even say much about it, that there was a total lack of intellectual curiosity in his work. And that meant there was nothing in his work that you could interrogate or learn about or inquire into or interpret or do anything as an art critic. And actually, he was genuinely clueless. So he's on record as being asked about his favorite artists in the Louvre. And he said, well, there are so many. You can't remember all the names. So in other words, he had no intellectual framework to order and understand the history of art and its traditions, his own discipline. The best description I've read of him is that he has an intention deficit disorder, that he just delivers paint onto a canvas without any understanding or idea of what he's doing or why. He doesn't have a problem to solve. He's just an aimless, hobbyist paint or some kind of amateurish bungler. And at the same time, he was desperate for recognition and ridiculed by the art establishment. So he was forever, well, not quite forever, but mostly an outsider looking in longingly at the art world but oblivious to his own inadequacies as an artist and of the actual work that was taking place in the art world. And he thought he was a painter of great importance. And he relentlessly exhibited his pictures wherever he could. And although he loved and admired the works and the artists in the Academy, it's pretty doubtful whether he could see past the surface of those canvases either. So he endured years of sustained mockery from artists, critics, and the public. And people literally would queue up, would line up to laugh at his paintings when they were exhibited.  So that's the naive artist.  So here's the naive programmer, the amateurish bungler at work again. The naive programmer is as ripe for a laugh as the naive artist, limited and unaware of their limitations. And this isn't a problem of style. Style guide is not going to solve this. It's not even that the code may be a little messy. The problem is the code reviewer here hasn't actually identified the problems. The problem is that these are just symptoms. The problem is that the programmer here has a crippling lack of resources to bring to the business of programming. The naive programmer's thinking is impoverished, and it comes out in their work. The naive programmer is a weaker, less effective, less complete craftsperson who will always be limited by their lack of sophistication. And it's not something to be proud of. But this is a funny thing that this photograph of Onryusso was taken by Pablo Picasso. Because, oh, he's packing Picasso again with another couple of Rousseau's canvases, Picasso was absolutely fascinated by Rousseau. Picasso was like Braque, an artistic giant. But Rousseau had something that Picasso didn't and that Picasso wanted. Picasso saw in Rousseau's naivety not just a lack or something negative, a deficit, but also something positive, a new way of seeing and representing what is seen. And certainly Rousseau lacked any sophistication. But as Picasso had enough insight to see, he had other things. He had a powerful artistic vision, and he burned completely obsessively with it. He developed a style and a language of painting that was all his own. And he may have been limited and confined to his particular style, but it was his invention and he created it out of nowhere. So he was a genuinely creative artist in that respect. He may have been oblivious to the problems in art that others were trying to address. He may have been even unable to articulate his own problems in any satisfactory way. But I think that if you look at his art, you can see that he is struggling, however inadequately, with a genuine problem field of his own. So he was naive and unable to connect with the dialogue of the history of art. But other artists, more sophisticated than he, were able to do that work for him and to see the connections through his own work. He came up with something new and became part of the history of art. So without ever developing in sophistication, Rousseau became a major figure, a major painter, in the history of art. He was an influence on Picasso, on the Cubists, on the Surrealists, on the German Expressionists, on Kandinsky, and then became an important part of the whole story of modernism, which of course extends right beyond, far beyond art. So now we have two different models for the encounter between sophistication and naivety to work with. We've got the example from modern art in which the naive is something that can be understood, valued, and learned from. And then we have this model. And I have some questions about this, because the fact is that even according to this, the naive programmer has built a house. Maybe there's something new in that building. Maybe there's something valuable worth learning from amidst the eccentricity and the bungling. What did the programmer discover along the way doing that? And the fact is that despite the lack of sophistication and education, the naive programmer was able to create something worth reviewing in the first place. Maybe that's evidence of creativity, or vision, or insight, or maybe even just of perseverance. And all of those things, I think, are worth something. Maybe there's a natural talent there that just hasn't been educated yet. And the fact is that it compiled without errors. He's not asking for his code to be debugged. He's asking for his code to be improved, to be made more sophisticated. He's trying to open up a dialogue. And I think that the naive programmer deserved much better than this particular sophisticated code reviewer, because she's not going to see past his lack of sophistication to anything of value that might be there in the code. Rousseau is one of many artists who is of complete naivety, who has made a serious contribution to art. And since Rousseau, art has been very alive and sensitive to what they might be able to offer. And if there are naive programmers with similar powers of vision and invention, then I think our world of software should be looking out for them too. Here's another naive artist. Mike Disfarmer, a photographer, a small town pod photographer in rural Arkansas, where he maintained a portrait studio in Heber Springs, this tiny town of 1,500 people. And he would make what were called penny portraits, or three for 50 cents in his very basic studio. And he was so naive that he didn't even know he was an artist. In fact, nobody knew he was an artist until about 20 years after his death, when a huge cache of all his negatives was discovered and published. And he became an international sensation in photography in the 1970s. And all he did was take studio portraits of local people. Just as living, they would come on a Saturday to have their photos taken. He wasn't part of any art establishment. He wasn't even up to date with the basic developments in photography. So he didn't use any larger. He made contact prints from his glass plate negatives for about 30 years after everyone else had started using film. So that would be like finding that somebody here is still storing their programs on punch cards, because they hadn't heard about any other developments since then. But what's really remarkable is this work that he produced. So his unassuming portraits of these small town, mostly rather care-worn looking people, and they weren't created as artworks. They were just his job. And these pictures are intimate and moving and really startling. They're composed with incredible skill and care. So for example, he was a master of lighting, whose only source of lighting was a single north-facing skylight. And you can see the kind of tired hands and the sad eyes of the people in these pictures. This is a really sad picture. Her name is Emma Mae Hoy. And she's dressed up in a little bit of a sailor uniform because it was present for her husband, who was in the Navy during the Second World War. And these pictures are light years away from the typical output of the small town studios of that era. There are no cliches. He didn't retouch any photographs. He didn't use any of the standard poses that you will find in photos from that time. And that's probably because he was so naive. He didn't even know what they were. He hadn't even encountered or learned them. So they're these songs of sadness and beauty. And he only has one song. It's always the same song, but it's such a beautiful one. Like Rousseau, the only resources he had were his own. He had nothing else to draw upon. He wasn't part of any artistic culture. And unlike Rousseau, he didn't even have pretensions to join it. So these extraordinary photographs came from nothing but his astounding eye for people. And they're such beautiful compositions. And I don't know if you can see them from every angle of the room, but I can assure you, you do not get to make photographs like this unless you know exactly what it is that you're doing. And yet this was the only thing he knew how to do. It was his only song. He didn't have versatility or range. And unlike Rousseau, it seems likely that he wasn't even aware of a world of art outside his studio that he wasn't a part of. He lived in his own little world doing his job, pictures for his customers. And maybe in programming, there are Mike disfarmers, too, working away, producing little masterpieces of their own that nobody else knows about. And this is really important because not every programmer is or has to be a software professional. Some are just completely normal people who, for some reason, have dared to write a computer program. So think about all the offices and workplaces and factories and laboratories around the world where someone with a problem has allowed themselves to imagine that they could solve it or by themselves by writing a computer program. And we occasionally meet people like these, but they don't come to our Python conferences. They've picked up a book on Python and learned something and built something. And they've done them in their own little worlds, not part of our culture, unaware of our wider culture, working in their own eccentric and peculiar and naive ways that they arrived at on their own because they found something that worked and nobody else was around to show them anything better or more sophisticated. And you know when you meet them because they're the ones who haven't heard of version control or separation of concerns or automated testing. Or you'll find them doing things like writing their code in Windows Notepad or using an online environment in a web browser because they couldn't get one working on their own computer. At the same time, software development is a profession. And like any profession, it has to put out barriers of exclusion, whether explicit or implicit, to maintain standards and quality to guarantee the, to protect the profession itself. Software professionals, I hope you agree, should not be using outdated practices or tools or doing things that we regard as poor practice. So in programming, we very rightly tend to pay a lot of attention to how we work and we don't hesitate to make comments and remarks about their tools and practices. But not every programmer has to be a software professional so they don't need to be measured by those standards. And there are more of these programmers than you think. And they definitely aren't coming to our conferences. I want to know how many naive programmers are out there solving their problems in their own way, whatever way that works for them. And I'd like to know what things, what remarkable things they might be inventing all on their own. And what problems are being solved unbeknownst to the rest of us. And I want to know what is the implication of this for those programmers, even if it's not directed at them personally, or even what's the implication of this for those programmers if they hear such a thing. Now, I mean, many of you know Jacob who as well as being an extremely accomplished programmer is also a very kind and generous man and wouldn't be using that to put down anyone. It's not intended to put anyone down. At the same time, I wonder what it does for those naive programmers. And also I don't think it's true if I may dare to say that to Jacob because if a Django girl goes into work the week after her first introduction to programming and writes a program that solves a problem is it broken by design because she didn't write tests or she wrote it in Python too or didn't use version control or if a graduate student in some lab realizes that she can solve a problem for her lab with some code, are we entitled to call it broken in any respect however deficient it might be by the standards of professional software developers or what about the designer who puts together a few lines of code in Django for the first time and creates something that stores and publishes a bit of data that he needed to display on his website. Under what circumstances do we get to call those things broken because they don't conform to the standards of our profession and we're putting programming into the hands of more and more people like primary school children for example whom we don't expect all to become software professionals. We don't expect all these people to have formal professional training as programmers. We just want them to know a little bit about programming so that they can use it in their lives and work. And if we're going to do that, we're going to find that increasing numbers of people are these naive programmers and these people absolutely rightly will consider that programming is just a means to their ends. The only purpose of it is to solve their problems. That's the only standard that they're interested in. So we better get used to having more of these naive programmers around us and also used to having less room for making confident proclamations about what is broken by design. Here's my final choice for exploring artistic naivety. When I was a teenager, did nobody recognize this? Oh, maybe I've got to put a name there. When I was a teenager, I discovered that the records of talking heads and that turned out to be a really important part of my education. This is the Tina Weymouth, the bass guitar player of talking heads and I was a little bit in love with her. I think still, because I thought she was the coolest thing ever. Here are all the talking heads and people really admired them for their incredibly long necks. Yeah, let's just look at that. So between 1977 and 1988, they released 10 albums of exceptional creativity and quality. As artists, they hit the ground running. They were already quite sophisticated in their approach to their craft because they'd all in fact been to art school and they followed their first record with three more that they recorded with Brian Eno of increasing depth and complexity and their work progressively digs deeper and reaches further. And at first, I mostly just liked the sound they made. I liked the sound of the music but later through reading about them, not on my own because as I said, sophistication comes through education. You can't become sophisticated on your own. I realized that something else was going on and this was my first introduction, my first real understanding of sophistication as an artistic quality. And you can play these records one after the other and trace this artistic journey, this development and there's the immediate response to the music but then there's this other level to explore that also itself yields more and gives back more as their sophistication as artists deepened and by the time of their fifth studio album, they were masters of their craft and the speaking in tongues, their fifth studio album was reviewed in the Wall Street Journal, that's how important they were. They followed up speaking in tongues with a tour from which the concert film Stop Making Sense was made directed by Jonathan Demi and this film is described often as being one of the best concert films ever made. Now, since it's a genre mostly filled with garbage, that doesn't necessarily mean pretty much but actually it is a rather brilliant film. So here they are in a rather low resolution but with an expanded nine piece version of their band captured at a moment of total artistic triumph. I imagine that God probably sometimes watches this film just to remind himself how good it is and what makes something like this worth returning to over and over again is its multi-dimensionality, its multiplicity of layers of connections, the fact that it has the same depth of artistic and intellectual curiosity that you will find in the work of someone like Georges Brack. Now, for talking heads, a really important part aspect of this sophistication was the attention they paid to practice and this is something that programmers like many other artists are familiar with. Programmers are fascinated by process and practice. Sometimes it seems they are more interested in that than in what they actually produce while they're practicing. So here's a nice joke I've found about programmers and musicians. So I don't know if you can see this. Here's craft work, inventing electronic music, standing desks and scrum meetings all at the same time. So of course programmers love that because it's about programmers. And programmers are really convinced that they just have to get the process right and everything else will work. And that's something that they do share with artists. An attention to practice is something you see in sophisticated crafts people. The artist Peter Schmidt collaborated with Brian Eno producing a set of cards for creative practitioners called oblique strategies and they're intended for artists to pull out in the work to suggest a course of action or a change in thinking to assist. So we have, what wouldn't you do or abandon normal instruments or give way to your worst impulse? And Eno used these cards with David Bowie on the three albums they recorded in Berlin. Talking Heads recorded three albums with Eno as well but they didn't use the oblique strategies actually because they'd already been to art school. They were already acutely aware of process and practice in art and they had their own strategies to fresh and stale habits and unblock stalled creative efforts. And their favorite technique was to swap instruments with each other in the studio so that each musician was playing something they weren't that good at. This is often how they composed music but through improvising and swapping these instruments was a way of forcing themselves into sideways turn out of ruts, out of dead ends, out of tired old grooves because with unfamiliar instruments in their hands their playing became less expert and had to be simpler and they made more mistakes and they stumbled across more unexpected things. It made them less sophisticated and more naive. They went deliberately into the naive to bring forth something new. As a band Talking Heads reinvented themselves seriously and continually and surprisingly for their entire existence with great sophistication and one key to their ability to do this was their understanding of the power of naivety in creative work. How are we doing for time? Somebody got a clue? Another 20 minutes? Okay. So for much of the speaking and tongues record the Talking Heads explored this very dark tone. It's kind of seething and festering with menace and paranoia. It opens with a song burning down the house which itself opens with a warning, watch out. And so it's a very sinister record and many of the songs seem to conjure up images or impressions of madness or sin or some kind of disaster licking at the edges of the world. And they've marshaled this brilliantly and they're doing exactly what they wanted to do. You can tell this is a group of artists right in complete command of what they're doing. But the last song on the record this must be The Place takes a completely different turn. It's the most beautiful song on the album and it's the smallest, simplest song. It's so small and simple and unassuming that most reviewers or many reviewers at the time somehow didn't even notice it was there. It just has three chords all the way through. And it has a parenthetical title which is completely accurate. And it's unlike pretty much any other Talking Heads song until that point and the most tender. So we've got this record of this side-winding swampy funk and arriving at this song is like arriving at a gentle dawn and blinking into it after you spent a turbulent night in the company of demons and exorcists. So it's a very strange ending for that record because speaking in tongues it starts with a song about burning down the house and it ends with a song about being home. And when you look back you can see this song as a signpost of the direction the band would take over the next two studio albums and explicit artistic inquiry into the possibilities of naivety. So not much was said about that song at the time but in the intervening 35 years it seems to have become quite important. It's taken on a life of its own meaning in the last 10 years mostly Talking Heads songs have not been adopted or recorded by other musicians. They seem to resist it somehow but this must be the place has been recorded many times. It's been used in numerous film soundtracks even a Paolo Sorrentino film named after it with Sean Penn, I haven't seen this. I just discovered this while I was researching this. And my question is, why has this little song flowered so late in life? There's much richer material on the record. It's not the song that I would have expected to suddenly flower 35 years later but there's now a generation of people for whom this is the best known song often because other people have recorded it. Maybe because of its simplicity that allows it to function as a canvas. Maybe it gives people more room to understand it in their own way. Maybe its naivety speaks more directly to people. Talking Heads were very serious in this pursuit of naivety. This was the record Little Creatures After Speaking in Tongues. This is a painting by Howard Finster who's another very well known naiv artist. So they were very deliberately diving down that road. Now earlier I said that being naiv is not a thing to be proud of. I think that's true. It would be like being proud of being ignorant. And sophistication is necessary to be a complete programmer and its absence is a deficit. But sophistication is not all that's required to be in command of your craft and it's not a substitute for any of the other things for technique or creativity or judgment and worse the pursuit of sophistication can come at their expense and the artist can become jaded and stale and the history of art is littered with artists whose sophistication left no room for those other qualities. And I'm pretty sure the same has happened to programmers. I had to choose. I would rather be a naiv expert, sorry, a naiv in expert programmer with a creative vision than a sophisticated expert who could solve all the standard problems but who had seized to invent any new problems of their own to explore.   Many of you will genuinely be much more sophisticated programmers than I will ever be. So it's especially nice for me to have that honor. And if you saw my code, probably even now, it was a little bit messy and my code, when I wrote it, didn't have tests and it wasn't elegant and perhaps in some way it was like something built by a child with only a vague idea of how to do it and little idea of how to use the tools. It was naiv, but more importantly for me, it worked. And I built a house if you want to call it that and the house stood and it did the job it was supposed to do and it did it much better than the creations of some much more sophisticated and I should say expensive programmers had worked. It delivered the institution that I was working for, something that it very badly needed and it saved it many thousands of pounds over several years. As a means to an end, it was a success. It served the institution and it served the people who worked there. So it was of value and I can be proud of that. So these figures and stories that I've discussed all represent different models of the relationship between sophistication and naivety and of all of them, this is the only one without any value.  So without sophistication, you're an incomplete programmer. It matters, its absence is a deficit in both the art and the artist. If you're aspiring to master your craft, you need to develop this sophistication along with your other qualities.  You can settle for being a good sophisticated programmer not a world-changing one. So you need to try and be like Georges Braque in your work and you're probably not going to be a Picasso either but you can be like Picasso, a sophisticated practitioner who is able not just to see past the deficits and limitations of the naive to its powers and gifts but also to take advantage of them or you could be like talking heads, sophisticated masters of their art, swapping instruments deliberately in the studio to draw upon the naive as a creative resource, finding new ways to remain fresh and inventive, stepping outside sophistication deliberately to allow new and unexpected solutions to reveal themselves. Or maybe you'll never be sophisticated like Henri Rousseau but still it would be a prouder thing to be a Rousseau whatever your limitations producing work of incandescent invention than to be a tired old sophisticate of the academy. And if you're a programmer, however naive you have every right to be proud when you exercise your powers and you solve problems. Whoever those problems belong to whether they're only yours or small ones. Even if your grasp of the craft is in some respects badly deficient if you solve problems for anyone that's something to be proud of. Or you could be a disfarmer. So naive that you're barely aware of the culture and traditions of your craft but working quietly producing modest creations of unassuming beauty. In other words as a programmer producing work of small but meaningful value to someone. However naive and limited your style might be. So these are useful ways for us to think about our relationship with our craft. And if I've said just one thing that makes a single programmer feel better about their lack of expertise or makes a single programmer hesitate before pouring scorn on the naive then I think that's worth something. And in modern art since the early 20th century the naive has had a really important and influential place. The adventures of Henri Rousseau took place more than a century ago and he lacked sophistication he was an incomplete lesser flawed artist. But whatever his artistic deficits we now judge him much more kindly than we judge the sophisticates who ridiculed and dismissed him at the time. Because he lacked sophistication but they lacked artistic vision and that's much worse. And I can't wait for programmers to learn the same lessons. Thank you very much. And I apologize because I was generously given a few more minutes and I greedily took them. Okay, so we have a few more questions. It's fairly simple economic theory that the more you restrict entry into a profession or occupation the higher the rewards for being in that occupation is classic example for this is taxi drivers with their licenses. So is there not a challenge that whilst intellectually and morally we think we should try and encourage naivety in terms of hard cash actually scorning amateurs is in all of our interests? I don't want to encourage naivety necessarily unless you're pursuing it deliberately as an artistic strategy but I want to encourage people who are naïve not to feel excluded and to have a go and to encourage people who are sophisticated to look past the limitations of the naïve. Now I think I said earlier that software development is a profession and must protect itself. You won't want to fly on an airplane whose software has been programmed by naïve bunglers. So I'm not saying that it's not important and the industry needs to protect itself in that way but there's a lot more than just this narrow industry I think and I think that's where the opening should be. And after all, of course, naïve people do become sophisticated through education if they want to. Thank you for that talk very thought provoking. I'm not sure what I'm thinking but I'm thinking about stuff. So what kind of techniques have you come across in your journey to kind of this realization to kind of how can we help stir up that process? Cause it seems like once you get it, you're like, ah, this is why something was done that way and kind of while also trying to balance me as a team leader, it can kind of sometimes be, you can be accused of being indulgent in kind of stop and think and what does this mean? What practical things have you seen to kind of help push people either up the sophistication curve or to help someone come down to it to maybe make a breakthrough? It depends on your team, I think. So if your team is of professional software developers, I think it's part of their professional obligation to develop this sophistication. So people would regard it as having failed in his artistic obligations because of his lack of intellectual curiosity. And professional software developers who lack that intellectual curiosity about their own work are possibly in the wrong profession. But that doesn't mean that not every programmer has to be one of those. And there can be programmers doing very valuable work. So for example, your team of professionals might work with designers or data scientists or human interaction experts or something like that who see a way to solve a problem with some code. Now, it would be a mistake to apply the standards of the software professionals onto those people. But you have to find a way for those people to work together. So maybe the software professionals need to become better at turning these insights from these more naive programmers into something more robust and saleable and sustainable. I'm not quite sure if I answered your question, but that's a reminder. So what were you milestones on the journey from naive to sophisticated programmer? My milestones? No, I am a naive programmer. I'm still a naive programmer. I'm not a sophisticated programmer. And I don't think I'm ever going to be. So most of my work. I do programming, but I'm slower than my colleagues. I think of dollar ways of doing things. But I bring other benefits to the team. So they don't need me to do that kind of thing. And I do regret not having that. But maybe it would come at the expense of other things that I'm more sophisticated in. Like spelling. You can't have everything. I started programming at the age of 39. So some of you have had a head start. I'm a naive programmer. Somehow I got into the industry via journalism. Should I bother becoming sophisticated? Well, it's an education. It's out there for you to take. And this is what's so interesting. I love listening to programmers talk about the way these concepts fall under their hands. So I'm standing with a programmer at the traffic lights. He pressed the button. He said, ah, greedy consumption of green signals.  And I think it's really empowering. And there's a lot to learn from that. But maybe your background is in something else.  Maybe as a journalist, you have an understanding about what the code should do in a satisfactory society. Or you might have ideas about how people understand information that a young programmer or even an old programmer does not. So I'm not going to give you career advice in your path. It's not a thing to be proud of to be naive. But if that's what you are, then you are. And you can still be proud of your work. It's just one doesn't want to wave a flag boasting of being naive. That to me doesn't make sense. But your work, by all means, be proud of that. So comment and then a question. The comment is, I don't know what the word for below naive is, but that's how I felt when I, you know, with all the art stuff. And that's really inspired me to kind of go away and learn more about my art history and all of those things. So thank you very much for that. But the question is, so who would you consider to be sophisticated when it comes to software? Like, do you have some role models that if I, because at the minute I don't know what it might mean to be sophisticated? For me, the most obvious people are some of my colleagues, for example, who are extremely sophisticated in the way they're able to think about problems in programming, which sometimes literally leaves me feeling awed. When I say something's awesome, I don't mean just quite nice. I mean, literally I feel awed by it. Or my colleagues on the Django Core team. There are some people there who are not just the best programmers in our community. There must be some of the best programmers in the industry in the way they work. Probably there are some of those people in this room. Anyone who is a master of their craft can fill you with a bit of awe when you see them get to work. Thank you for your talk. I'm just wondering, is it possible for a sophisticated programmer to lead innovation in the world in any field, such as science or medicine or anything else? I don't see why not, as long as they have the requisite skills and capacities for them to be able to step outside maybe the slightly narrow world of programming into the rest of the world. I'm a bit nervous when I see software-led innovations in the world like Naomi's terrifying flying Uber car over the skies of Paris. I'm not going to visit Paris for a while until that thing is grounded, that's for sure. Because I definitely don't trust programmers who are only programmers to lead very much except the development of software. And this experience of the wider world that you want from a scientist or a politician or somebody in business, I think has to come from outside the world of programming. Because they might be sophisticated about programming, but they might be extremely naive about all kinds of other things to our detriment. Hi, Daniela. Thanks for that. Just a quick question. What I try to grasp is that we are talking about the naive and the expert as individuals. And I'll give you an example from my job that I can solve the maths. I can write the basic algorithm. I can write your reports after reports on how things are calculated. I can do the basic Python code. Then I need someone to take it from there and deliver a graphical user interface, solve all the take-inter problems that I will just throw in the way. So what if we have an artist, one person does the sketch, and the artist knows how to color, colors it, and we work in collaboration to make something of certain use? So what do you think of that, really? Can we match the naive and practical with the experts? This is the story of Henri Rousseau and Georges Braque, that, sorry, of Rousseau and Picasso, that Rousseau, he had this insight or he had this vision, and then he couldn't even go so far because of his limitations. But it took someone like Picasso to actually understand even better than Rousseau understood what it was that Rousseau was doing. Because Rousseau had a vision, but he didn't really have much understanding of it and he was scratching at his artistic problem sometimes successfully and sometimes not so successfully, but when you look at his work in the context of the history of art and, for example, questions about perspective and use of color, and you see what Picasso does with those things, then without Picasso, I mean, in fact, without Picasso, Rousseau, we probably wouldn't know much about Rousseau because Picasso one day stumbled across some frames of Rousseaus that were being sold to be painted over.  And he championed Rousseau. There's a very famous kind of symposium, a banquet that was held in Rousseau's honor. You can read about it, it's quite funny, by Picasso. It was slightly, well, you'd have to read about it. But so I think that the naive programmer, if that's what you're describing yourself as, doing a particular task in engineering needs somebody who will champion her work, who will see past, maybe you've got some limitations in your code, and pull out the value, help you pull out the value, help make that value stick in code that's really robust and works and can be delivered to do a real job. And you need that kind of sensitivity because if you have the unsophisticated code reviewer, that's running into a brick wall. Thank you very much, Daniel, for the talk.


Let's get over to our man Mr. Basil Chapman as we do each and every Tuesday at 20 past the hour. And don't forget folks, Bazaars are an outstanding show here every trading day, 10 to 11 Eastern Santa time, also has a great newsletter, the opening call. Now it's very easy to get the opening call folks, come over to our website at TFNN, you're going to see it right under featured content, the opening call. You just hit that subscribe button, you can get the opening call for one month for $149. You can get it for six months for $695 which is a savings of $199 or 22% and you can get it for one year for $1195 which is a savings of $593 or 33%. Now they all come folks with a 30 day money back guarantee. As soon as you subscribe, bottom line you're going to get all of Basil's archives, he's got 10 to 12 webinars out there that are phenomenal to understand how this market moves each and every day. So Chapman, what's going on? Hi Tom, how are you doing there? I'm doing great yourself. Very good, thank you. So this is going to be quite a week here man. You know what's interesting, here we are, if you listen to the news, just every hour of the day there's something really negative. Just look at this chart here, it's not incredibly bullish but it's not very bearish when you think about all the news with Walmart, normally under other circumstances at other times over the decades, Walmart drops like it did, that would just be devastating. So I'm kind of impressed with the, not necessarily the ruggedness but with the rolling corrections throughout each sector so that there's always something that's helping the market. In this case the Dow is down 231 points, made a high just three days ago, 32,219. This left side chart with the data just gives an incredible amount of information. The MACD is good, the MACD that's moving average conversions to divergence, the stochastic is at 89%, that's really nice, on balance one is very disappointing, that's the one area and I do respect the on balance one because it isn't running sharply with the price but it does mean that if there is a break to the over the 32,220 area to start a leg D any time this week, there's a chance that we'll have to wait for the on balance volume to become oversold just as it did when it went to a high back on the 27th of May as the Dow was making that cluster formation top and then it pulled back very sharply. So I'm kind of impressed and we are still at both the dollar and the Dow I should say and at the same time holding this particular chapwave inside track, it was a repellent zone, you can see how many times it's been repelled from that area, now it's holding it, it's above it, so it's really important over the next couple of days they really start to test the 32,000 on the way up. So that to me is important, I don't want to see a break below 31,500 that will actually be very negative. So yes it does trend a lot on the results, of course we've got just tons of earnings coming out, stocks coming out with the earnings this week. So we'll see what happens but most importantly if we can survive in the weekly chart that's the one in the middle, if we can survive this week by Friday at least having one pop to the 32,250s, doesn't have to close it just has to get there because you can see the MACD in the weekly chart, this is the first time since way back at that peak D back in October, November of last year that the moving average convergence divergence histogram that's the 0% line is about to turn positive, it's really close hasn't done it yet but if it does turn positive it gives some strength rather than deflecting lower like it's done almost every other time, so this is going to be an important moment and the stochastic is improving it's not great at 32% and the weekly chart on balance volume is really poor and of course we'll have to wait until Friday at the close at 4 o'clock to see what the monthly chart looks like but so far it's holding well and I keep saying to you that there's been economists talk about recession but actually if you look at every single chart you can go to the semiconductor index you can go to let me just do the semiconductor index you can go from the double top of 318 from November then retested it exactly within pennies the week of the 7th of January and then it came down that's a recession 318 down to 189 if you look at the RTH that's the retail index it went from 200 down to 140 to me that's a recession so for the for the economists to give some kind of title to this whole thing saying there's a it's a recession well you've had a lot more than two quarters of very weak earnings look at even Sintas which I always look at as an economic barometer I went from 461 back in December down to the 340s and that was in June in a way you have to consider that as part of recession but when you look at the monthly chart hey for overalls uniform rentals really not bad 461 down to the 340s and now it's trading at 396 so there's a really mixed market and you can make of it whatever you want but I think that we've raised a lot of cash over the last months we started to put that to work and I think that what we're looking at here is that they're going to be survivors in this particular phase going into August and they're going to be some very weak stocks and the weak stocks like a target and a warm lot pertain to the over buying of goods and there's just a glut of those and I think that we're looking at certain areas that are starting to show some improvement and I like that and we try to find those we've done quite nicely in the in the shorter term and I hope we can keep doing that we have actually just got into date into an oil and gas stock if you look at natural gas just look at this natural gas goes from a 915 the continuous contract back in June at a peak D in the Chapman wave cascade down to the low fives and today it hit for a 9441 so there are areas that are that are working and I think that that's really what you're going to be doing here you got to be very specific got to have cash ready for the next many weeks you're going to have opportunities sudden sell-offs and stocks that you've been wanting for a long time and they got away I think they're going to be coming in and I think it's a rotational market and as I said it's been a rotational recession through the different sectors and if they want the full title forget it in the next week or two but usually what happens when the economy says recession that's usually when you start to find some kind of a bottoming process but we'll see what happens are we being very specific we actually went into a financial the other day one of the in the financial sector the XLF is holding quite well not great but quite well but certain stocks within that are doing okay and I think that's what we're doing we just being very selective for subscribers to my opening call and making fairly tight stops and so far it's worked out quite well and folks it's very easy to get Bowser's newsletter so just come over to our website at TfN you're gonna see it right on the featured content you just hit that subscribe button and you are off to the races you have a great night safe night and of course we're gonna have some action after the close we got Microsoft we got Google coming out plus other ones but those two no doubt it's gonna be driving the NASDAQ very important yes thank you Tom thanks so much have a great one Basil have a safe one we look forward to show in the morning yes thank you


Thank you Cornelia. Thank you to the TOC. Thank you to all of the people who contribute to the technical advisory groups within the CNCF. Now before we leave we've got a few housekeeping items. First and foremost, don't forget to take care of yourself. We understand that returning to an in-person event can be as overwhelming as being stuck in your home for 18 months. This is a good time to refresh your knowledge of the code of conduct and remember that we are all humans and kindness goes a long way. For our virtual audiences information on staying healthy can be found on the wellness and interactive sessions page. For our in-person attendees, don't miss our outdoor refresh lounges where you can get a breath of fresh air and our quiet rooms if you just need an interaction-free moment. Also within the online wellness interactive sessions page you can find information about virtual game night and both a happy hour and a coffee clutch with CNCF Executive Director Priyanka. With us in LA don't forget to come mingle with our exhibitors at the welcome reception at the booth crawl in the solution showcase. You won't want to miss California's favorite burger. I know I won't and if you're joining online visit our virtual booths and participate in our live office hours with our exhibitors. After each session you attend today we would appreciate you leaving feedback on skedge.com which can be found on the session schedule page. I want to highlight this because this is what helps us get new content and making sure that we're staying relevant to you. New content is like 101 student track and anything else that evolves to our community needs so please give us your feedback we are listening. Lastly there are a few folks we want to thank because without them none of this would be possible. All of our sponsors as well as our diversity scholarship sponsors please take the time to visit the sponsors in their onsite and virtual booths in the solution showcase throughout the event. And last but certainly not least our incredible program committee and track chairs who worked tirelessly like seriously I'm reading these things but like tirelessly to put this on so thank you for helping us select the sessions. So thank you for joining us for today's keynotes breakout sessions begin at 11 a.m. and we hope you have a great day see you back here tomorrow.


It's my favorite, because we get to talk about pathways. And the reason why we're talking about pathways is because the nervous system coordinates pathways, communication pathways, and so does the endocrine system. Comparing and contrasting these two kinds of pathways, do that, like I should write my exam right now because that's a phenomenal exam question, like a five-pointer would be compare and contrast nervous and endocrine pathways. Somebody remind me that I said that so I can actually put it on the exam. Big similarities, very significant differences. Both endocrine and nervous pathways begin with what? Stimulus. And tell me, is the stimulus an anatomical structure? I'm going to get cranky if you try to tell me that the stimulus is an anatomical structure. The stimulus is, like, totally not an anatomical structure. It's something that initiates the pathway. An interesting difference between nervous system and endocrine system. Nervous system, the stimulus often is outside, something external, something in the environment. If it is, if the stimulus is being detected by somatic sensory receptors, it is something external that is causing the message. In the endocrine system, it's always inside. And I say that knowing full well that maybe there is an endocrine, like a stimulus to the endocrine gland that actually does come from the outside, but I don't think so. So if you think of one, tell me because I want to know. Both of them start with the stimulus. Both of them end with what? A response. Is a response an anatomical structure? No, never. Responses, what happens? Both of them have these non-anatomical things. Let's do the nervous system side first because that will, like, remind us of what is familiar. The stimulus is, okay, I've got to find my perfect orange. The stimulus is picked up, oh, good God, I don't think I can use that color, I'm sorry. That's not going to work for me. Let's try, that'll work. Nobody knows. I know it doesn't matter. Stimulus comes in, okay, and is picked up by what? Anatomical structure, a sensory receptor. That's an anatomical structure. The sensory receptor translates the stimulus into what? A message, an electrical message via an afferent path. Do you agree with that? And the afferent path was what? Some kind of nerve. Do you agree with that? The afferent path takes the message to whom? Do a neural integrator, or let's just say integrator because we will see that pathways can get totally complicated and neural pathways and endocrine pathways can actually interact with each other. The integrator receives the information, processes it, and generates an output signal. The output signal goes how? Through the afferent path. Do you agree with that? Of course you do, because that's how it rolls. The afferent path delivers a message to whom? The effector. The effector generates the response, okay? That's super familiar, right? All right, let's talk about the endocrine system. The stimulus, the stimulus is usually going to be something inside, like something almost in the blood that is going to stimulate the endocrine system. And the fact is that the thing that distinguishes it is that, yes, we sort of have a sensory receptor, but we sort of don't. Now watch what I'm about to do. I'm taking this sensory receptor and the afferent path and the integrator and putting them all in one box, because the sensor, or the sensor, like what you would think of as a sensory receptor, they actually call it a sensor in the endocrine system. The sensor is the integrator. So the stimulus comes in and it, what? It stimulates the sensor. The sensor is the integrator and what is this? What is this if we're in the endocrine system? This is endocrine, like, how am I going to label this? Endocrine gland or cell. There is no other sensory receptor. There is no afferent path. And I've always thought of endocrine glands as like they're just integrators. But it's like how does the integrator get the message to do something? There's a sensor on the integrator. And the sensor picks up the stimulus, whatever it is, low blood calcium, high glucose concentration, more metabolism needed, like something triggers this. The integrator senses that. After that, the integrator is going to actually dump or create an output signal. Now I'm going to label it like that. I guess I'm in the right color because the output signal is the afferent path. But what was true about what is, like, tell me what's the nature of the output signal? It's a hormone. This right here is a hormone. Where does it get dumped? More pictionary. It gets dumped into the blood. So the integrator, the endocrine gland, dumps hormone into the blood. That hormone is the output signal. As far as I'm concerned, you can think of that as an afferent path. It's like the same thing. They don't call it an afferent path because it's not directional. It's in the blood. So it's literally going to have access to going anywhere. So there's no directional information with output signal. There's no directional information with endocrine system, which is why they call it an output signal. Here goes the message out into the world. Afferent path is directional from central nervous system to effector in that direction. An afferent path is never any other direction except integrator to effector. The output signal goes all over the body through the bloodstream. There's not an actual direction associated. I hope that makes sense because I said it about 8,000 times. Now, guess who's the same? The output signal heads out to a, I want to call it an effector because that makes it consistent, but often in the endocrine system, we call it a target. And we can mess with that in physio. The effector generates the response. Now, it's actually not crazy, is it? Like that, like the only weird thing is that the sensor is the integrator and then we've got a little bit of different terminology, but I could totally see this on exam and quizzes. Like we'll throw this thing on the quiz. So get comfortable with that and be able to compare and contrast, be able to throw in specific, never mind.  Maybe I will by the time I actually have class because yeah, I'm delirious because I'm nocturnal. All right, there's something I was going to say, oh, you can stack them. What? You can stack these things.  The endocrine cell, the ant pit, is the sensor, receives the message, has the right receptor, whatever receives that message and then is the integrator generating the hormone, which gets dumped into the blood, heads on out to an effector, awesome, or it can head to another freaking endocrine gland. Are you kidding me? Like we can pile these things on and get very complex pathways. Do you think there are any complex pathways in your body? Those of you guys out there who are taking anatomy and physiology and doing these things together at the same time, like you guys are getting to actually go into the physio at the same time as your anatomy, I have to wait. I'll try to be patient while I'm waiting and in the meantime, you probably want me to stop talking. What? You do? You don't want to just listen to me all night? I mean, it's only 1.30 in the morning. We could keep going. Yeah, hopefully it's not 1.30 in the morning where you are. All right, endocrine system rocks. I will holla at ya later.


South Africa's constitutional court on Tuesday ruled that former president Jacob Zuma was in contempt of courts. That's because he failed to appear at a corruption inquiry earlier this year. The court also ordered that Zuma be imprisoned for 15 months. The former president failed to appear at the inquiry led by Deputy Chief Justice Raymond Zundo in February. The inquiry is examining allegations of high-level graft during Zuma's period in power from 2009 to 2018. But Zuma denies wrongdoing and is so far not cooperated. In the final analysis, the constitutional court makes the following order. 1. The application for direct access is granted. 2. The Helen Seussman Foundation is admitted as Amicus Corriai. 3. It is declared that Mr. Jacob Geleshe Yisazuma is guilty of the crime of contempt of court for failure to comply with the order made by this court in signature of the Judicial Commission of Inquiry into allegations of state capture, corruption and fraud in the public sector, including organs of state versus Jacob Geleshe Yisazuma. Mr. Jacob 4, Mr. Jacob Geleshe Yisazuma is sentenced to undergo 15 months imprisonment. 5. Mr. Jacob Geleshe Yisazuma is ordered to submit himself to the South African Police at Nganjla Police Station or Johannesburg Central Police Station within five calendar days from the date of this order. Hello. Hope you enjoyed the news. Do subscribe to our YouTube channel and don't forget to hit the notification button so you get notified about fresh news updates.


Thank you very much for the introduction, like the gracious man said, I am Justin Mayer. I won't be taking questions after the talk, but I would love to connect with people. I would love to talk to you about some of these topics, so by all means, please come up to me afterward. I'd be really excited to talk to you. Also post the slides on my site after the talk. You can see some links to Twitter and Mastodon for those new kids on Mastodon, and I'll post the links to the slides there when I'm done. So I'm originally from Los Angeles, California. Last year I moved to a small village in the Italian Alps. I work on software related to privacy and security, and I also write about it at JustinMayer.com. In my spare time, I maintain a few open source projects, including Pelican, which is a static site generator. And today I'm excited to talk to you about the Zen of Python dependency management with a little sprinkle of package release automation tacked on. So why is dependency management important? It's important because we share code with one another. We incorporate open source software that other people wrote into our applications and libraries in order to speed up development time and to improve the quality of the things that we ship. It doesn't make sense for a lot of us to write our own crypto libraries, so we go out and we find someone who knows tons more about that stuff than we do, and we grab the bits and pieces that are useful and we integrate them. The average package on PyPI relies on someone determined two or three dependent packages, which is not a big deal in and of itself, but that can have cascading effects where those depend on two or three other dependent packages. As you take this to its logical conclusion, you can see how you kind of have this rather significant dependency tree. And this is important also because of the notion of reproducible builds, and reproducible builds are important because, say, you're a company and you have new employees or you're an open source project and you have new users, you want them to be able to bootstrap your project as easily as possible, and they can't really do that if they're getting dependency conflicts. And so this is a way of, among other things, making it so that they can easily get your software up and running. And you also have other environments. It's not just development. There's testing, staging, production. You want to make sure that the thing you're working on in one of those environments is going to behave in a similar way as possible in the other environments. So reproducible builds are important for that reason. Now, a related topic is packaging, and packaging is also important because I want to use code that someone else wrote for reasons that I just described. And I want that to be done as easily as possible, and packaging is what helps make that more facilitated and easy. And at the same time, I also want to share code with other people so that they might benefit from the stuff that I wrote and to make it as easily as possible for them to use it. So consequently, there's a lot of talks about packaging, and there's been a number of them here at this conference alone, which I think is really interesting, and they all kind of overlap in interesting ways. So the packaging ecosystem in 2018 looks a little bit like this. And I say 2018 because we'll talk about some of the newer ones. But so there's like some tools over there on the left, and there's some files over there on the right. And this is kind of what things look like today. And if anyone who knows anything about these tools and files can tell that over the years, packaging has kind of morphed and accumulated new appendages. And as it's kind of moved along, it's shed other things. But at some point, it kind of starts to look like this conglomeration of accreted bits over time. And I think that there's a tendency to look at it in a somewhat negative way. And I think the cool thing is that some people are saying, like, no, actually, maybe we can look at this a little differently and look at as we can celebrate all of these little bits. Does everyone know what a platypus is? I don't know that German or French words for platypus. So if you don't know, ask someone who does know a platypus is a creature, has a duck bill, it lays eggs, it's a mammal, it's a really strange animal. So someone came up with this idea, I wish I could give credit, but I can't recall where I saw it. But they said, we're gonna celebrate the strange and continuing evolution of Python's packaging systems. So I think a platypus is a great metaphor for Python packaging. And some of the things they mentioned are, as far as the metaphor, it's a bit odd to start with. But then you realize it's the result of evolution in very unique circumstances. And it's actually quite cute and friendly most of the time. And it can incapacitate a human with its venom, just like packaging. So it's really difficult to fully grasp the finer points of how these pieces fit together or how they have evolved to their present state. So I'm not gonna try, and I'm instead gonna focus on the tooling that exists today and some of their practical applications. For some of the finer points, Dustin Ingram, who works on PyPI, gave a great talk last year on PyPI and packaging and its history. Hinnick has given great talks, he gave one yesterday on how to manage a project when it's not your job. Mark Smith gave a great talk on packaging in general and how to get something on PyPI. I wanna talk a little bit about some of the new stuff. So there's PEP 517 and 518. 518 defines a new configuration file called the pyproject.toml file. And this has the potential, eventually, to replace setup.py requirements files, setup.config, manifest.in, and probably other configuration files I'm leaving out. It doesn't, this PEP is long, like most PEPs. But it actually specifies very little. It specifies a filename, the file format, which is toml, a build system table, and a tool table. It's a little bit like the Wild West with this right now, where every build system is allowed to put stuff in it and can kind of do the build however it wants. There's no real standard in terms of how they do that. Some folks feel like the side effect of this could be a kind of vendor lock-in where you use one particular tool and because there is no standard, then you're kind of locked into it and it'll be tough to migrate. I suppose that depends on how hard it is to convert how one tool defines their dependencies, say, in this file. And then to migrate that, we'll find out, still early stages. So the build system can be defined in this way. This is how you would define it in a setup tools context. For poetry, you define it like this and this basically just tells the system that we're using poetry to manage and build this project. You can add different configuration on a tool namespace level. This is how poetry keeps track of your dependencies. And you can only use a tool, you can only use a name in the tool namespace if you are the owner of that named package in PyPI. So let's talk a little bit about, so that's the pyproject.toml file, which will be relevant when we talk about some of these newer dependency management tools. And when I talk about them, I'm going to mention the dates of last release, when they were released last. Because that relates back to the first slide, which is why is packaging and dependency management important? And that's to distribute and share software. And software that's sitting in a version control system and not inside a shipped release is software that, for the most part, for average users may as well not exist. So to me, steady releases are an indicator of project health and thus are important. First, I'm going to talk about pip tools. So pip introduced requirements files, which allows you to pin your dependencies. You can have hashes of those dependencies so you know that the thing you are putting in your requirements file, when it installs, it will actually be that file and not something else. And this improved reproducible builds and security. The problem is that pin requirements get outdated, and they need updating from time to time, and that's a bit of a hassle.  The pip compile command lets you compile a requirements dot text file from your dependencies, and those can be specified either in setup.py or in a requirements.in file. Then you can use pip sync to take the compile requirements file and then update your virtual environment with the dependencies you've declared inside those requirements. And that makes sure that your different environments wherever they are, are fully up to date and reflect the requirements that you've specified. So that's a very focused tool, and it does something very discreet. In contrast, pip-env does a lot of things. It manages virtual environments, so you don't have to. It audits packages for security vulnerabilities. It does dependency resolution to make sure that one package might depend on a different version than another package needs. So like pip tools, it keeps your dependencies updated and your virtual environment current. It does this in the context of a pip file instead of a requirements file or the newer pyprojects.toml file. When I last used it, and I'm going to express opinions fairly freely, it was relatively slow. I don't know if the dependency resolution has improved since then, but it was a bit slow. And lots of software is opinionated, but I feel like pip-env is quite opinionated on the spectrum of opinionated software. It replaces the requirements.txt file, but not setup.py or setup.config or manifest or any of the other parts of the setup tools ecosystem. So you still have to manage all of that stuff. And you still have to put your high-level dependencies in setup.py and your pinned dependencies in your pip file. Just in terms of how the project is managed, it vendors a lot of packages. It uses its own patched versions of pip, of pip tools, and maybe other things. That's not really my style to just wholesale sweep a bunch of software into my repo, but I'm sure they're doing it because they have so many different things they're trying to accomplish, and it's the same way for them to manage it so I can understand the benefits there. Their virtual environment management, if you just want some other tool to manage your virtual environments, you don't want to know where they are, you don't want to know what they're named, you just want something else to do it, it's great for that. For me, I prefer to manage them myself, and so I felt like I was kind of struggling with it. One of the things it does is that I believe it hashes the path to your project, takes that hash, and then appends it to your virtual environment name, and when you sort of depend on a predictable virtual environment name for other tooling, this can be kind of problematic. Just a silly example is I use the fish shell, and I have tooling that shows me the virtual environment that's activated, and I don't want to see this big ugly hash in my prompt line every time, and so I had a really hard time getting around that, and that's obviously minor, but we have opinions. So this notion of unpredictable virtual environment names, like apparently I wasn't the only one who had a problem with this, there's lots of open issues about it, maintainers kind of were like, eh, we're not gonna address this any time soon, and they just keep closing them. But again, so by default, another thing to know is that when you run pip-env-add to add a new package, it updates your locked packages. Now, you can disable that, but for me, I found it to be a strange default. I just want to add this package to my project, and then all of a sudden it's starting to update all of my locked packages. So for me, it kind of violates the principle of least surprise, but again, you can disable it, and I'm sure they had good reasons for making that the default. The uninstall command will remove packages, but not its dependencies. So you have to use pip-env-clean to remove the dependencies. So it seems to me like it's an extra step, maybe there's good reasons to separate those steps, but it just wasn't what I expected. It can also manage .env files if you use environment variables and you want them loaded into your environment. That's cool if you need that. For me, I managed that at the shell level, so it was kind of like an extra feature that I didn't need. The initial paces for releases of pip-env was really insane, like it seemed like everything was just shifting out from under your feet in the beginning, and then it's kind of slowed, like projects as they mature tend to do, but the last release was like eight months ago, and at some point you start to wonder, again, they probably have good reasons. It's an important project for people and they don't want to break things, but it's a long time for there to not have improvements. It's opinionated, which is fine, but it's opinionated for me in ways that don't fit my mental model or workflow. I feel like they took on a lot, they kind of overpromised. For me, they underdeliver a little bit, and it seems like we bit off a bit more than we can chew and are kind of under the weight of all of that. Again, that's my assessment. Try it for yourself, reach your own conclusions. So poetry is a similar tool. It keeps your dependencies and virtual environments up to date fast and for me, more reliable dependency resolution. It manages virtual environments, but only if you want it to. For me, it didn't get in the way. It uses the new PyProjects.toml format. Unlike the other tools I mentioned, it does not rely on setup tools. It can also, unlike the other tools, can build and publish packages to PyPI, so if you are managing this particular project, you're also publishing it to PyPI, you don't need an extra tool at this point to do that. I feel like the project has managed very well. Some PRs get rejected because the author is trying to keep the core manageable, and I really respect that. One thing that some folks might run into, you cannot install into a specific virtual environment. You can't say like pip install dot dot virtual M foo. You can only install into an activated one or into the default home wherever you want that home to be. Another thing to note is that users will need pip 19 or higher to install packages that are built without setup tools. I also noticed that poetry generates a setup.py file. But there's not much documentation as to why I assume it's for backwards compatibility, but I'm curious to know a little bit more about what that's about. Only pure Python wheels are supported, so if you're trying to build anything with C code, this is not the tool for that just yet. When you build, it increments your version string in the pyproject.tombo file, but if you have version strings in other files, you'll have to manually track those down and replace them. There's only main and development environments, so there's nothing like you can't say I want a specific dependency section for testing or for releasing new things. There's some really good features in it marked for the 1.0 release, including a plugin system, which would help give a home to the rejected pull requests and still keep the core as lean as possible. I feel like that's a sensible way of managing things. There's per project configuration coming, which could be used, something like this, to specify a virtual environment on a per project basis, giving you a bit more control over where your virtual environment is. And also, incrementing version strings is also on the roadmap as a nice helper when building things. So in summary, I feel like it's managed well, it's updated regularly, it fits my mental model and workflow. This is a newer project with a sort of interesting choice of name. Dependency hell, wee, it's like a celebration of the thing it's carrying. So they're trying to support a lot of things in it, setup.py, requirements.text, pip file, poetry, they really seem to be like, we're gonna support every piece of this ecosystem. They audit packages for security vulnerabilities. It has like a pip x like ability to isolate command line tools in isolated virtual environments. It's trying to do a lot. It claims to be like better than all other tools, end quote, which to me always gives me pause, but it's a new project and I haven't given it a full run through. So something to have on your radar, perhaps. So at this point, I wanna talk about a related topic, which is release management. Once you've managed your dependencies, there is another step towards zen-like enlightenment because getting something that you're, getting your project onto PyPI has, there's simply too many steps and none of them are fun, and they're all of them are tedious.  You start manually updating version strings sometimes in more than one place.  There's just a lot of steps and usually another thing that people run into is only a subset of folks with commit bits usually have the ability to publish new packages on PyPI. Sometimes it's only one or two people. So this is a part of an open source project, ReadMe, that documents how maintainers can release new versions of this particular project. This screenshot shows five steps. There are 14 in total. The funny part is this project's purpose is to automate GitHub releases. So like I thought that was really interesting irony, but this is totally normal. The list for some of the projects that I maintain is even longer. So at some point, like did anyone see the Chernobyl TV series? This is how I feel like it's you have your clipboard and your list of steps and you're just hoping that you don't miss a step, you don't push the wrong button, you don't end up breaking the package for potentially a lot of users. And so it's a little bit stressful and a side result of that, whether it's conscious or not, is that we don't do it as often as maybe we want to or should. As in the personal anecdote, I once noticed that a year and a half had gone by since the last time I had issued a published release on PyPI and I was horrified to realize how much time had gone by. Because at this point, I feel like I'm failing at my job as a maintainer. It's a volunteer unpaid job, but it's still something where I feel responsibility to people and I don't want to let them down. So it's not good for maintainers because it's stressful. Well, it's also not good for users because you have this slow release cadence. And bug fixes and new features are sitting in the master branch. Hardly anyone is benefiting from them because they aren't in a shift release yet. PyPI account owner is on vacation and some critical bug fix gets merged by another maintainer. Well, it doesn't matter. You can't get it into a shift release. So you now have this critical bug that people are running into. So there are sort of bespoke, custom ways of automating this. And so you can use continuous integration to sort of take continuous integration one step further. So after it runs your tests, it can then say, okay, well, let's figure out a way to publish this and you can automate it and have that so it's not as manual and error-prone a process. So I wanna explore one way of how that might work. One way of doing that is by auto publishing releases upon a PR merge. So in this context, the pull request has to include a release file with two bits inside. One is the release type, major, minor, or patch. The other is a change log entry, description of the changes in that pull request. So the maintainer looks at the pull request and says, okay, tests are included, docs are included, code looks good, the release file is there, merges it. At that point, the continuous integration system can look for the release file and grab the major, minor version, the designation, increment the version. It can then take the description, prepend it to the change log and then run the equivalent of get add, get commit, get tag, get push, all of that and publish the release to PyPI. So there's some real benefits to doing this. With almost no human input, every code contribution results in a new release in a matter of minutes. Every feature and bug fix gets its own release without anyone having to remember to package and publish a new version. If a bug is found, it's now much easier to trace it to a specific release version. And of course, you don't have to use this, if you had the system in place, you could also issue releases manually at any point. But my favorite part about this notion is that all contributors get to issue their own releases. Like, what better way is there to welcome new contributors than to reward them with a dedicated release that's composed entirely of their work? I'm not saying it's right for all projects. For some, it may not be a good fit. If you maintain a library that is depended on by critical network infrastructure or services, maybe this isn't a good fit for you. Maybe you can figure out ways of making it work. Some maintainers may think, well, I don't want to see this release history clutter where every tiny little fix here and there results in this long list of releases. And it's true. Even something as minor as a typo fix gets its own release in this model. And, but I would encourage people who have this reaction to it, to really think about it. Like, would that be so bad? Would, you know, is that a serious problem? Is it a tidier, you know, history really worth sacrificing all the other benefits? So around this time, I was trying to solve this conundrum. I came across an article that describes this type of solution. And Hypothesis is a property-based testing library. They did a really nice write-up of how they arrived to this and how they solved it. And around, and then sometime afterward, I noticed that Patrick Arminia, who has a Python GraphQL library, was looking to do the same thing. And he asked his friend Marco if he could figure out a way of adding that same thing for Strawberry. And so he did that. He connected it up with CircleCI. And I really liked the simple, elegant approach that he took. And rather than taking the bits and customizing them and then copying and pasting those across multiple repositories that I managed, I thought it would be great if I could just use one tool and kind of just kind of pip install it into these different projects. And so, and then that way other maintainers could benefit from this as well. So I called Marco and I said, hey, I generalize this a bit. Is this something you wanna work on? He said, sure, if I have time, I would be totally up for that. And so I took his code, I added some more, I put it into its own GitHub and PyPI package and just pushed it last night, as a matter of fact. And so, to see how it could potentially work, this is a bit of configuration for CircleCI. And it's not obviously the whole thing. This is just the deploy step. And so you can kind of see, I know that the type is really, it's on a black background and it's super small, so you may not be able to see in the back. But essentially it runs through some of the normal steps that you would take using CI steps, modifying permissions, installing packages that you need. But it also then uses this new tool to do things that you would normally have to write your own scripts for. Checking for the release file, preparing the code for this new release, creating the commit, getting the commit into GitHub, getting the GitHub release created. So it's still very, very early stage. Feel free to check it out. All of the good bits in it are Marcos. All of the terrible broken bits are mine. There's lots of room for improvement and I would be very interested in any input or contributions to make it more flexible. It has very limited utility in terms of scope at the moment. It's meant for using CircleCI. It's meant for people using poetry. That could easily be, or at least somewhat easily broadened to do a little bit more. So I'm interested to see what people can do with some of these new improvements to the overall dependency management and packaging ecosystem. Because the overall goal is to make it easier to use helpful software that other people have written and to share the stuff that we do and to do that as frequently as possible. So with that goal in mind, I hope that you found this overview of dependency and release management to be enlightening. If you have any questions about this at all or just wanna chat, please come up and say hello. I would love to talk to you. Thanks very much for coming.