Lightning Talks Day 2

Speaker 1: Alright, some ground rules. Last time I gave this, it was a 40-minute talk, uh, and I caught the Django cold. So here's 35 slides in five minutes. If I get through it in time without sneezing, I expect wild applause. Thank you. I'm uh Matt Chapman. I work for M Pulse Mobile. I'm talking about cranial. We're not gonna have time for this agenda. We are uh you want to know what cranial is uh at its core it's an ontology to allow data engineers and data scientists and people working in different programming languages on different platforms to talk to each other in a common way about data engineering tasks, data science tasks. It's also a Python library set of uh actually four Python uh libraries with various modules and it implements many useful things.

Speaker 1: It was developed at uh Tribune Publishing for uh content recommendations for the Chicago Tribune, the LA Times, other major newspapers, and other related Machine learning services. So if you use any of these technologies on this list, there's a good chance there is something in Cranial that might be useful to you And if you use any competitors to any of these technologies, it should be very, very easy for you to wrap your usage of those technologies in a simple class that will allow you to integrate with the rest of the cranial framework. So these are some things that I believe if you believe these things too then uh you will love cranial if you don't I can't do anything for you by the way because I have to go through this so fast you're gonna have to read the slides while I'm talking. There's some jokes hidden in there. I'm not gonna have time to tell them Uh good luck. So what can Cranial do for you?

Speaker 1: The the goal is that uh it will accelerate your time to market so that data scientists can build data models that are ready to go into production and do useful things like make predictions off of web requests or take database inputs and and transform them into useful outputs. It should promote standard uh interfaces and reusable code. If you use cranial on one project, you should have lots of useful things you can use for your next project. And it should allow you to move between different technologies very easily. So if you're using one database for one project and you hit scaling problems on that and you need to move up to Amazon Redshift or Google Big query or something like that, it should be very, very simple to swap those components out and have your software keep working the way you intend. Where did Channel come from? I told you it came from uh the content recommendation system work at uh

Speaker 1: but it did prove successful and the things we built there were very useful for other uh machine learning and data engineering tasks. Uh so uh one of the core objects that you need to know about in Cranial is a model. If you get nothing else, you can think of a model as a pure function. A model transforms a record. If you're implementing a model, you only have to implement one method on that class. It takes in a record, it outputs a record. Where does the model come from? Uh the you make them, but uh they can be made of lots of things. Uh what is a record? You probably want to know that at this point. Uh a record is like a key-value data structure, so a Python dictionary can be an example of a record. So a model transforms records. Typically that runs inside of a service that does something useful, a web service that takes web requests, an executable that processes And puts out a different kind of CSV

Speaker 1: or puts things into a database or puts it on a uh streaming uh messaging broker. So what's inside of a model? You have multiple steps. Those steps can be simple functions. They can also be other models. So you can have models inside of models inside of models and do uh whatever kind of recursion you want. That's maybe not necessarily the best way to compose models, but uh it's doable. Much more interesting than uh static models that that simply uh transform records uh through various steps. are models that have state. So if you're a front-end developer, you're familiar with uh Redux. Uh I discovered Redux after uh developing Cranial and uh it's all got all the same great ideas that we need to keep our state contained in one specific clear place that's separated. This allows us to save our state for

Speaker 1: distributed systems, for backup and recovery, for point in time analysis, lots of great things. Keep your state in one place, whether you're using cranial or anything else. So if stateful model , regular model has one method, the stateful model has one more, and you store a state on it, and you get a bunch of useful stuff for saving and loading states. Cranial was actually developed around like a lot of machine learning is done on uh offline. You take a bunch of data, you train on it, you produce a model, you put that model into some kind of web service that makes predictions for weeks. You collect more data, then you train it again some weeks later. Maybe it's better, maybe it's worse. You upload it. Cranial was uh designed, thinking of that as just one way of doing uh machine learning, but focused on online learning so that we are constantly training our model in production. We're constantly learning whether that's one record at a time, 200 records at a time, retraining our model every two minutes.

Speaker 1: Uh cranials for online machine learning if you're using it for machine learning. It's also got lots of other useful stuff. Listeners and fetchers get uh data into your model. If you need to scale up your training because uh you've got a huge data set, need to train over millions of records, the short chart shows you how to do it. Connectors are a useful abstraction for putting things in byte streams. A file is a byte stream. You want to save things to files, use a connector. Connectors and fetchers are a little different, ones for data scientists, one's for engineers. Uh we keep going it's services that have other models in them can all talk to each other. We have a messenger, you use service discovery to help them find each other You can use a message broker if you want, but you don't have to. These things are all very similar, but these slides will help you figure out the different messaging queuck, but they don't, just use them correctly. Uh fetchers and listeners uh are

Speaker 1: how you move data around. ETL is done too. There's where you find it. Thank you.

Speaker 2: We're gonna go with uh Vim Bond OS. How many people here are familiar with Windows? How many of you like developing on Windows? Yes, thank you. Thank you. Um I too like developing on Windows. How many people here are familiar with Vim specifically? tool called named V-E-N V. Right. So actually uh a good number of you. Uh how about virtual inv? There you go, that's a lot more. Um Vim sips standard with uh standard with Python, virtual limb doesn't. Uh Piffinv also doesn't, and uh I I'm I used to use um virtual inv on Linux in a uh in a virtual box. Um and I

Speaker 2: had to be basically a Linux sysadmin to run my virtual box, and then I had to uh map a whole bunch of stuff and I had to be a networking guy. Oh, and I had to secure Linux. And I didn't really like doing that. So um after I destroyed my virtual box for the nth number of times, I decided, what if there I I wonder if there's a way. So Python works on Windows, so if I could use something to manage my dependencies that ships with Python, then it should probably also work on Windows. So I give it a shot and oh my god it worked. So here's the agenda preWex installing PyTRM debugging. Let's go to prereqs. Oh, I'm gonna show you PyCharm and how to debug in PyCharm. Um This is a command prompt. Um

Speaker 2: it's Windows, so I can't zoom in. I apologize. I didn't say Windows was good. Also Um when you get into compiling binaries, go use Linux. Yeah. I'm not saying Windows is good. So um first steps first, we're gonna do this. We're going to make a folder. So Then we're going to make a virtual environment and we're going to move into it. Then we're going to make a virtual environment. So Oh Python, this is important. Python -mvimvim. So I said make me a vim. That was the first vimv. And then I said name my vim vimv because I don't really feel like

Speaker 2: oh I'm actually sort of deactivated because I'm in another Vim right now. So through the magic of um through the magic of television Activate uh activate This is Viv Scripts activate Me too. Anyhow, it works, okay?

Speaker 2: So we're just gonna go and say through the magic of um television, here is one of them that I already did. We're gonna open uh this directory in PyCharm, you're gonna notice that PyCharm has no idea what to do with it, but it starts to figure stuff out because that's what PyCharm is good at. That's what that little bar in the corner is doing. Um I'm still figuring things out. The only thing that I installed in here was um well was Django. I I went made it to the bottom of these steps, but because I'm Django running out of time. I'm not gonna type those in. Um PyCharm is still figuring things out through the magic of television.

Speaker 2: Do the magic of television Uh PyTrum's not gonna play nice with me. If everything works the way it's supposed to work quickly, then you will end up with PyCharm connected to to uh the directory where you started your project inside of Vim having installed Django and PyCharm will automatically uh identify uh everything about your project, the fact that it's Django, and all you will have to do is hit play. At which point you will have an application. Oh, and this is Tim's blog project. It's called Um Peregrine and it's awesome, and you guys should all check it out.

Speaker 3: The most important decision that business people make are not what decisions, but who decisions. This is Jim Collins, the author of Good to Great. Is anyone here responsible for hiring? Are any of you confident about your hiring process? Got one back there. Hiring is one of the most difficult, time-consuming, and critically important responsibilities that I have. The average hiring mistake costs a company 15 times that person's base salary. Mishiring a 100K employee will cost you $1. 5 million on average. According to management guru Peter Drucker and others, 50% of all hiring decisions are mistakes. Executive discretionary time is overwhelmingly less than 5 to 10 hours per week.

Speaker 3: With the rest of the time consumed by meetings, reports, one-on-ones, et cetera. When an urgent need for hiring comes along, prioritizing the time needed is deeply and profoundly inconvenient. Changing priorities is hard, so many managers will force fit their hiring activities into the small slices of time on their calendars. Hurried interviews result in decisions being made based on gut feelings and first impressions The structure of the typical interview process often discourages frank conversation and rarely leaves time enough for intelligent questions. One of the basic failures in the hiring process is too much reliance on the resume. What is a resume? It is generally a record of a person's career with all the accomplishments embellished and all the failures removed.

Speaker 3: If this sounds like your hiring process, here's what you need to do. Make hiring your top priority. Dedicate no less than 50% of your time to hiring activities. This means attending fewer meetings and delegating, perhaps temporarily, more of your responsibilities. Trust your team and rely on them. Define a thorough hiring process before you start hiring. I recommend modeling your hiring process after the book Who, the A method for hiring. So, what does my hiring process look like? First, who am I looking to hire? A candidate who has at least a 90% chance of achieving a set of outcomes that only the top 10% of candidates could achieve. Next, I create a hiring blueprint. This is called a scorecard in the Who

Speaker 3: Book that defines what would change in the organization if the right person was hired right now. A list of outcomes, exactly what must be accomplished. ideally only achievable by the top 10% of possible candidates. A list of competencies that are required to fit with the culture of the company and team while achieving those outcomes. The blueprint is critical. It forces you to be crystal clear about what you really want the person you're hiring to accomplish. It also creates a consensus on the team about the expectations for the candidate. And you can share it with your candidate to properly set expectations for the role. Next, create a pitch for the position. This is more than just a job description. Most of the candidates we want to hire already have jobs and they're not actively looking. Why should one of those candidates leave their job and come work on our team?

Speaker 3: A successful hiring pitch will go beyond just a list of responsibilities by including the following components. The team-company mission, a purpose that candidates should really get excited about. Minimum requirements. This conveys that we have standards, responsibilities. What will I actually be doing day to day? Highly desired skills. These are things that we really need help with. Compensation, salary range if possible, PTO holidays, and other relevant benefits. And the interview process, if they apply, what's the expected commitment? About us, relevant fun facts about our company and team. My team prefers to write code that is aesthetic, readable, and solves problems. And high-pressure interviews are not a good indicator of that A work sample project is a simplified version of a problem that we've had to solve.

Speaker 3: Create a small task or project that accurately represents the role and can be completed in less than one hour with the following criteria. Timed, because untimed projects ask too much of candidates and biased towards candidates with fewer outside commitments. Representative, it aligns with what their day-to-day work will look like. Unique, they've never seen this problem exactly before. Engaging, the problem can be split into phases that build upon each other. In summary, one, create your hiring blueprint, two, create the pitch. Three, create a small and large work sample. Four. Every candidate is required to complete the same initial work sample. Five. Score all work samples using the same rubric. 6. Schedule phone conversations with the top 10% of candidates. 7.

Speaker 3: Schedule the larger work sample with interested candidates. 8. score all using the same rubric. Nine schedule on-site face-to-face interviews to evaluate for cultural fit. And ten, if you find the candidate who has at least a ninety percent chance of achieving the set of outcomes you define Do everything you can to hire that person. You have any questions or comments, feel free to talk to me. Thank you.

Speaker 4: Great, your friends. I'm gonna keep going. So I'm here to talk about elephants and snakes. But in order to talk about elephants and snakes, I have to talk about birds. Specifically, the big blue bird that encourages myself and many others to put that at Feldini. On our slides and business cards and websites. I'm talking about Twitter, of course. Twitter is great. It's where we find work or chat with our peers or share our favorite activities or even find romance. Twitter is also awful. It's the place where the most misguided amongst us feel free to express every negative opinion, where we are constantly inundated with reminders of violence or targeted with violence ourselves. Where it seems like the political bombs are always going off, and where it feels like we have to wade through toxic waste just to get to the parts that we like. This is not to blame most of the people who work at Twitter.

Speaker 4: I know many Twitter folks, I'm sure people People in this room, no bit too many Twitter folks. Some of you in this room might be Twitter folks. And I firmly believe that most people at Twitter don't wake up in the morning and go, ah, I can't wait for another day providing an outlet for white supremacists. But Twitter has misaligned incentives than most of its user base because it is a business and a bit and an ad business to boot, and those businesses need to make money. There is an alternative, however, and that alternative is the Fediverse and its most popular implementation, Mastodon. Mastodon is an open source microblogging service that looks very much like TweetDeck circa 2012, and it's based on a W3C standard called ActivityPub. Because it's based on an open federated standard, anyone can write clients and servers that talk to all the other clients and servers on the federated network.

Speaker 4: What this means is instead of having one big watering hole where the rules are opaque and you're never quite sure who you're talking to, you now have a field of connected communities that can all talk to each other, and where you most likely know the rules of the smaller community. community you're part of and probably know the admins by name. That's part of the power of Macedon that every community can define its own codes of behavior and still connect to the rest of the world. The admins of each server can respond to complaints and enforce the kinds of community Communities we want to be part of. There are over 1. 6 million users in the federated network, and they're all part of smaller communities working together. It's kinda hard to overstate how much power there is for creating communities in Macedon. Admins can set codes of conduct, upload custom emoji, mute or block users, and even mute or block bad actor servers if the community

Speaker 4: But this is a Python conference, specifically a Django conference. For developers, especially Python developers, there's a full set of clients and libraries to build any kind of experience you want on top of activity. And the Mastodon software. No arbitrary limits from Twitter, no ever-shifting usage guidelines, just a public API that you can build against. We can have all the things we like from the community we've built on Twitter without having to feel like we're swimming in that toxic waste dump. We will have to accept a less polished experience for now, and the fact that not everyone we want to follow is on Macedon yet, but every friend we convince to try something new makes the network stronger and helps us take back control over the communities we care about. So I hope I've at least convinced you to give Mastodon a try. I would love for you to come up and talk to me more about this throughout the rest of the conference, maybe talk about the servers that I'm currently admitting.

Speaker 4: And I hope to see you on Mastodon. Thank you so much.

Speaker 5: Alright, so my name is Kaz and that's my dog Ada. That's her Instagram. If you want to get a hold of me on social media, that's kinda the only way to really. So I'm a tech lead at Rover. What does that mean? It means I don't write quite as much code as I used to write, but I write a lot more plans and a lot more tickets. So I'm going to talk to you today about that. Um, I'm gonna start with one of my favorite quotes from a great American philosopher, which is that everyone has a plan until they get punched in the face. So pretty much all my plans start with step one: get punched in the face. in the mouth. Um preferably before you start shipping code. So really one of the best reasons to write a plan is that it lets you kind of explore what you're going to do before you go do it. and maybe find some of those places where you might get punched in the mouth before they happen.

Speaker 5: Um so what do we put in our plans at Rover? We put, first of all, like what we're doing. Like A recent plan that we did was we're gonna add support for adding cats. So what are we gonna do? We're going to make it so you can add a cat on Rover as easily as you can add a dog. And then why are we doing it? In this case, because there's a lot of cat owners out there. And previously it was like to make a cat you had to make a dog whose breed was cat. And that's just as a cat owner. No, no. So then the meat of the plan is how we're gonna do it. We have kind of a checklist of things. So kind of an overview of what we're gonna do to the code base. Not necessarily like line for line, here's what we're gonna do, but maybe like okay, we're gonna go in this app, do kind of these things here, can go in this other app, do this, take inspiration from X, Y, Z, then a plan of how we're gonna test it, how we're gonna monitor it, uh, how to document it, and then any kind of data storage requirements that we might have.

Speaker 5: Are we adding tables? Is there, you know user security implications to that? Do we have to follow GDPR for these tables, et cetera? And then the most important part of a plan is Getting it reviewed. Um we have a pretty large organization, so we kind of have to be circumspect about who we ask to review our plans to not just ask too much time of them. So if I'm making a lot of front-end changes in my plan, I'm gonna have a front-end engineer look at it. If I'm gonna touch the database, have a database engineer look on it. On a smaller team, you might just have everybody look at it so they kind of know what you're doing. And on a team of one, like it's still a good idea to write a plan and then sleep on it and like look at it again the next day, see if it still makes sense And you know, be ready to make changes. Like a blend 's if you're gonna have it reviewed, it's gonna be a lot like a code review. Um don't take things personally if people are like, hey, do this a different way.

Speaker 5: Um it's generally from their own past mistakes. And if you're reviewing a plan, be constructive, just like code reviews. The more fun part for me is writing tickets. So tickets can be as simple as just a you know to-do list that you have. And here's my thoughts on tickets. They're a way to encapsulate work. There's many different ways to write them. My way is one of ways to write them, and it's probably definitely not the best way to do. So. However, you know, it's been used without catastrophic results. And ideally, tickets make work more efficient. So what goes into a good ticket? Well, a ticket should describe a reasonably sized bit of work. Um it could be anything from a few minutes to a few days worth of work. But if it gets any bigger than that, like maybe it should be smaller. Break it into more discrete steps.

Speaker 5: And a ticket should contain at a minimum a title and a definition of done. And a ticket could also contain some implementation notes if there's more details than can fit in a title and a definition. have done. It's also known as the description. Um so what's a title? A title sums up a ticket in a sentence or less. And it should be written like a good commit message. It should be short. should be descriptive and it should be completely devoid of unnecessary detail. That's what everything else in the tickets for. Um it should describe the work at a high enough level that anyone who has read the underlying plan can explain why this work's being done. Um so what's the definition of done? It's to me the most important part of a ticket. It doesn't describe what needs to be done. It describes the end state once this has been done, once this work has been done.

Speaker 5: So instead of describing a path to this state, by describing an end state, the focus is placed on the outcome, not on the process. That removes a lot of ambiguity. You can say, is this done? Well, is this true? And it also lets the person who's actually doing the ticket, you know, have some amount of flexibility and creativity. And then finally, if a ticket's really complex or there are references and assets that'll assist to be needed in the implementation, if there's details, there's links, there's files that should be added as notes. They're you know kind of the most freeform part of the ticket. And really a good sign of when you should add notes is if the definition of done starts growing beyond a sentence or two, generally a sign that you should probably write some notes. And that's all I got. Here's some pictures of my dog for listening to me rant.

Speaker 6: Thank you very much, Kaz.

Speaker 7: So hi. Uh my name is Andrew Pencombe. I am the founder of Jambon Software, which is a consulting company. That spends a whole lot of time building in Django and a proud Django Con sponsor. We're a consulting company. We build things as well as consult. We built this thing called Cert Cycle, which uh is a an automated system for provisioning, installing, and checking security certificates in the cloud. So if you're interested in and automated security on AWS or Azure, please come chat with me. In the community though, I am probably best known for my book Django Unleashed, which was published by Pearson in 2015 and which we are doing a video series. So that should be the first video series should be coming out November and May. beginning of December, hopefully

Speaker 7: on Safari Books Online. But I'm actually here today to talk to you about coverage for Django templates. Or so I had sort of initially So uh when I I told someone this morning uh that I was going to be talking about coverage for Django templates, they said that sounds horribly, horribly bor boring. You should talk about the hamster on your shirt. Um there's a problem. There isn't a hamster on my shirt. This is impossible, that's right. Thank you, person in the crowd. Um so this is this is a bear from the Bravest Warriors YouTube show. Uh and Impossi Bear comes with a gas powered stick, which is what it says on my shirt. It's great because it's a a stick that never runs out of gas. And

Speaker 7: like Impossibear, I would like to give you a gas-powered stick, so I'm going to tell you about coverage for Django templates. So this is this is fairly straightforward, right? When you are testing with Django, you are either going to be using the Django uh unit test space to Django run system, maybe you've gone nuts and you've uh brought in PyTest with PyTest Django, which is actually super cool. And while you are testing your your Python, you might bring in uh coverage uh written by uh Ned. Um I'm going to say Suddenly. Thank you. But so that's great for your Python, but how do you go ahead and test your Django templates? Well, lo and behold, Ned has also gone ahead and written something called the Django cover template. plugin and you can just pip install it and then add it to plugins

Speaker 7: and you're off to the races. So lo and behold this is actual output from a test. You can see that it goes through and it runs the test. And then in the coverage output you can see that it is included not only Python, but it's also included the HTML templates. And you can see that I have have missed a few. And this is the cool thing here, is that it's useful not only for testing the conditions and branches in your template logic, it's also useful if you are doing any sort of integration testing. So here I've actually pulled in, I'm writing templates for uh Django registration, but I have failed to test some of the integration behavior on my website. So again, helpful not only for your own template code, but also for indirect information about the integration with third-party tools.

Speaker 7: Um part of the reason I'm bringing this up is because I'm actually the newest co-maintainer on the project with Ned and Pam. So I'm going to be interested in uh improving documentation, logging, and use. So on top of trying to to make it so that you have the ability to test your templates. I am interested in hearing uh what you how how have you uh sort of what is your experience with this? If you're new to this, I would like to try and help you get started with the the uh cover template plugin. And if you are already using this, I would like to hear about your experience. So thank you very much. I hope that was informative.

Speaker 8: Thank you. Hi, yes, my name is Mariara and you can follow me on Twitter. I am one of the Python core developers. One of my favorite favorite features of Python is called F strings. And you're probably wondering what For some of you who haven't upgraded to the late newer Python version, still using Python 2. 7, you're wondering what are F -strings Is the new way to format strings. And you can do this if you have Python 3. 6. And how do you do it? So remember how you used to format by uh format strings like this with present something don't do this don't ever do this don't don't make me see this kind of code when you make pull requests to python don't

Speaker 8: There are a diff there is a different way to format strings with string format, right? Using curly braces, passing in variables in there. F -strings work very similar to that. Basically you cut off the dot format in the back there and just put an F in front. But that's that's it. That's an F-strings. And let's learn about some more terminologies of F strings. So things inside the curly braces there. Those are called expressions. And things outside of the curly braces are called the literal. And you can definitely use capital F In an F string, if you're just feeling excited about it, like F, yes, you can put capital F, it works.

Speaker 8: And you can use it with single quotes, double quotes, um, double triple quotes. Triple single quotes, all of this works whichever you like. You can combine it with raw strings into Raw F strings and you can do it like F and R or R and F, that works. But you cannot combine it with Unicode strings, so you cannot have U and F or the other way around, not F B or the other way around. That doesn't work. You'll get syntax error You can call functions inside the expression part, passing parameters like that.

Speaker 8: You can use format specifiers. So here is an example of formatting date time object inside the expression of F-strings. So use it. It is actually faster than string format. Oops. You can get it if you have Python 3. 6, if you use Python 3. 7, that's great. 3. 8 is due to out Soon January um Alpha 380 Alpha One will come out January. Yes. And you can get this for free, free of charge. You don't have to pay anything. Go to python. org. If you are not using Windows or Mac, maybe you want to build it from source, or if it doesn't come from in your

Speaker 8: operating system, maybe you should just Consider changing a different operating systems like one of these. Um all of these works So if you really really want to know more, if you're excited about this, I actually gave a really longer talk about F -strings. Yes, it was possible. I gave it a talk at PyCon Canada last year All about PEP 498. That's the PUB that proposes and implements F-strings. Um Yeah, and I have lots of stickers. Use it proudly, put it on your laptop. I I still have a little stash left. That's all. Please use F strings. Um while you're going to python. org and downloading the new version of Python

Speaker 8: Um may I ask you all to please do fill in this Python developer survey to help the PSF Python Software Foundation who helps the community who helps run Python infrastructure. helpful in this survey and um yeah thank you all.