We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

There’s a Snake in the Birdhouse!

00:00

Formal Metadata

Title
There’s a Snake in the Birdhouse!
Subtitle
Building a Python Culture at Vrbo
Title of Series
Number of Parts
130
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
It’s no surprise why many of us are so enamored with Python. Its simplicity, accessibility, and community make it a prime choice for many projects. However, not all software engineering shops use Python, maybe even some of the jobs you work at. Introducing Python to your company and building a Pythonic culture from the ground up is no small task, but it can be done. Join me as I take you through the journey of getting Python from zero to hero within my previous company. I’ll share the experience from start to finish, including what worked, what didn’t, what I would have done differently, and how I evangelized Python to bring it to be a supported language within my company’s ecosystem. Viewers will leave having learned from my experiences—both successes and mistakes—and with a solid plan for implementing Python at their job.
Active contour modelActive contour modelType theoryComputer configurationBuildingXMLUMLMeeting/Interview
Active contour modelSoftware developerWebsiteTemplate (C++)Mobile appComputing platformVirtual machineGauge theoryHTTP cookieDefault (computer science)BuildingFluid staticsExecution unitSoftware testingMathematical analysisMetric systemPersonal digital assistantCartesian coordinate systemSet (mathematics)Expected valueVapor barrierProduct (business)CuboidConfiguration spaceComputer fileChatterbotMachine learningMobile appIntegrated development environmentPoint (geometry)ResultantLattice (order)Multiplication signUnit testingLikelihood functionDatabaseAlgorithmSystem callKey (cryptography)LaptopLevel (video gaming)Latent heatBuildingCASE <Informatik>Metric systemFigurate numberLoginJava appletPhysical system1 (number)PlanningVirtual machineSoftware testingMathematical analysisFormal languageProjective planeComputing platformFluid staticsBitActive contour modelHTTP cookieDefault (computer science)Sampling (statistics)WebsiteTrailElectronic mailing listTemplate (C++)Process (computing)Ocean currentSoftware developerData managementScaling (geometry)AreaImage resolutionStandard deviationDifferent (Kate Ryan album)Execution unitNP-hardRuby on RailsComputer animation
Personal digital assistantLatent heatBuildingActive contour modelDefault (computer science)Decision theoryRevision controlMultiplication signProduct (business)Message passingHash functionCore dumpMereologyCASE <Informatik>Latent heatDecision theoryFluid staticsPhysical systemStrategy gameBoundary value problemCodeInterface (computing)BitGoodness of fitDatabaseFormal grammarOpen sourceForcing (mathematics)Sheaf (mathematics)Axiom of choiceComputer configurationLibrary (computing)Cartesian coordinate systemImage resolutionRight angleBlogUnit testingElectronic program guideSoftware bugEntire functionData managementProcess (computing)Different (Kate Ryan album)Computer fileLimit (category theory)Software developerCode refactoringRevision controlError messageCuboidString (computer science)Line (geometry)Projective planeWeb 2.0Computing platformPlug-in (computing)Internet service providerMathematical analysisDefault (computer science)WritingExecution unitMobile appSoftware testingSynchronization1 (number)Computer animation
Revision controlActive contour modelLocal GroupSoftware testingFeedbackWritingProof theorySoftwareFormal languageSyntaxbaumRewritingComplex (psychology)Multiplication signSoftware maintenancePhysical systemTwitterCartesian coordinate systemGoodness of fitLevel (video gaming)Proper mapSource codeData managementNatural numberMessage passingInternet forumProduct (business)Formal languageBitCore dumpLoginProcess (computing)Field (computer science)ResultantSoftware bugTraffic reportingDifferent (Kate Ryan album)Projective planeSoftware developerService (economics)Group actionThread (computing)Negative numberInheritance (object-oriented programming)CodeSoftware testingStreaming mediaWritingProof theory1 (number)Programming languageRevision controlComputer programmingFeedbackBeta functionBlack boxExistential quantificationSet (mathematics)Power (physics)SoftwareUsabilityBuildingMobile appSoftware engineeringBoss CorporationComputer animation
SyntaxbaumActive contour modelComputer animationMeeting/Interview
Transcript: English(auto-generated)
There is a snake in the birdhouse. Nice title. So, it's all yours. Remember, for everyone, you can ask questions at the end. And you can type the questions in the Q&A option
soon. Go. Thank you. Good luck. Awesome. Thank you very much. Hello, everyone. My name is Mason Egger, and today I will be presenting to you There's a Snake in the Birdhouse, Building a Python Culture at Vrbo. So quick introduction. I am currently a developer advocate at DigitalOcean. But before this,
I was a site reliability engineer at Vrbo, which used to be called HomeAway, which is kind of where the title of this talk comes from, as HomeAway's old logo used to be a birdhouse. So that was where it came from, and then they changed the name and
ruined the title of my talk, but there's nothing I can do about that. Still kind of works. When I first started at Vrbo, there was no official support for Python in the Vrbo ecosystem. I'm going to go into this a little bit more, but that's really kind of the starting point for it. And today I'm going to kind of tell you my experience
of how I led the effort to build a Python culture at Vrbo. This talk is a little bit different than some of my other talks before, because this one's really, really, I would say really anecdotal. I'm just going to basically tell you the story of what I faced when I got there, how I convinced my manager to allow me to start working on Python and start supporting Python in the ecosystem, and some of the lessons that I
learned and some things that I found that worked when I was trying to convince people to use Python, some things that I found that don't necessarily work so well. So that's what this talk is going to be about. So who is this talk for? I always do one of these. This talk is for anyone who uses Python at their current job, but
is currently, you use Python at your current job, but you're unable to like maybe use it in production or use it with more people, or maybe it's not quite supported. You want to build a stronger Python community at your current job, and you want to learn how to introduce or evangelize any
technology, not just Python. So a lot of these tips and tricks that I'm going to give you are, they work for Python, but in reality this is kind of how to evangelize and teach things on a broader scale, not just necessarily Python. Hopefully you'll be able to learn from my successes and my
mistakes to bring Python or any technology that you wish to use into your current work environment. So a little bit of background on the way that the systems work at Verbo. So engineers at Verbo deployed applications to an internal PaaS that my team built. So if you wanted to deploy
an application, you basically would create a Docker file with your application inside of it, follow a list of instructions that we gave such as tell us where your logs are, tell us what port your health check is going to be going across, whether or not you want live tracking, what environment you are, just a whole list of things. And they would deploy it out
to this PaaS, that was not Kubernetes based by the way, because it was built before Kubernetes was even a thing, and that's basically what served all of the VRBO website, the Verbo website, and now has actually been migrated into the Expedia ecosystem. At the time that I started, there were project templates that existed for the supported languages of
the company. Verbo had initially started as a Ruby on Rails shop, but by the time I got there, almost all of the Ruby on Rails was pretty much gone. There was a little bit of lingering remnants, but none of it inside of our ecosystem, inside of the ecosystem that I maintained. The supported languages that we had were Java and Node, and what this essentially meant was is that you
could go into a, basically an application generator, so say you had a new idea and you wanted to create something, we had a whole fancy system where you would go in, answer a few questions, and a project would automatically be generated for you, and then it would be ready to deploy into this ecosystem, and would even be deployed automatically into the test ecosystem, so you could kind of see it working
very similar to say how a one-click works at DigitalOcean or sample applications work in other PaaS systems. So at that time, Java and then Node.js were the only two that were supported in this way. You could go what we called off-road with your applications, which meant in reality, the specs for the
platform were very vague. As long as you, you know, had a health check and, you know, told us where to find your logs and all these things, the language didn't really matter, so you could build a Python app if you wanted to, and in fact there was, I think, a handful, not a lot, but there were a handful of Python apps when I started, but there was no official support. So if your application started
misbehaving, if something started breaking and you couldn't figure out why it was doing this, then you would be kind of on your own. Like, we might be able to help you, but in reality there was no official team that supported this. The Java and Node archetypes had their own team for this. So you could go off-road, but you really didn't want to, so that led me
to kind of start the question, hey, let's start using Python. Verbo at that time was starting to get really into the machine learning and AI kind of things for some of the chatbots and things that we were building, but the workflows for that were not on the new system and the ones that were were very sub-optimal. So we decided to start figuring out,
hey, what would it take for us to do that? And that leads to essentially a discovery meeting. So if you are trying to get a language set up at your company and you haven't really, you know, you're just starting, you're going to need to have a discovery meeting with key stakeholders. So you're going to want to meet
with all of the people who you think might be useful or who might be interested in consuming this. So for me, I met with the data science teams, I met with the machine learning teams, and I met with some of the API teams to gauge the interest. Because as we know Python and Flask is a great way of building great APIs and data science and
machine learning, well, that's just kind of where everything was, at least at Verbo, everything was being done in Python. So we led a discovery meeting and this, after kind of pitching a couple of ideas, I come up with my first, what I call, don't. And my first don't would be don't build something that nobody wants. So some of the things that I was talking about was Flask application or Django applications with databases
and those other kind of things. And nobody really wanted that. In reality, what they wanted was they wanted a way to either run basic data science or machine learning algorithms or notebooks and stuff, or they wanted to just create simple APIs and they didn't really want like the full
Django experience. So I quickly was like, okay, I evaluated what people wanted and I decided, hey, let's not build what, don't build something that somebody doesn't want. So we talked with these teams, figure out what the interest level is and what you may want to actually build. Like what would they actually use and then it becomes valuable to them. Another great don't
that is here is don't develop in isolation or avoid others opinions. If I, say I had just decided to build the Django app and what I was originally envisioning in my head and didn't get any buy-in, yes it would have worked but nobody would have wanted it. So you definitely want to get others
opinions and make sure that there are people who are excited to use this product. If it's not really, if it doesn't excite them then the likelihood of them trying to use it isn't any good and you'll waste a whole bunch of time trying to evangelize a language that nobody really wanted to use in the first place. So especially at these discovery meetings it's great to just get as many opinions as you can, ask everybody
in your company because you need to be able to like sift through all of that and come up with a definitive plan. And if you, and the other hard thing is, is luckily when I was at Vrbo everybody was interested but if you if you do a discovery meeting like this and nobody's interested then that's sad but it may not be the
best use of your time to continue down this path. If you can ease, if it's obvious to see that nobody's interested in adopting either Python or whatever you're trying to evangelize at that point. So the result of this meeting was I decided to end up building a cookie cutter that creates a default flask application for the platform that included
built-in static analysis, unit test, project documentation was already set up, logging, metrics that reported back to Datadog, the base application itself, all of these things were built in. The CICD with all of the configuration files for the build and the deployment were already built in so that is basically that's what we decided
that we were going to build off of. And what that leads to is build a complete product for them to use. Use that for, build something that everybody wants to use where they don't really, if you open it up and it's the out of the box experience is great and everybody's ready to use it that's awesome and people will use it. If they have to go and
like say they want static analysis but you didn't provide it they have to go add it in that's more work that's more of a barrier for entry to them provide them with everything you think they would need but make it easy to disable the things if they don't want them. So when I started building this archetype when I started building this application that everybody could use at Verbo I learned another
good one is create a meaningful set of expectations and use cases. Don't fall into the trap of this will solve everything. That's not a really good way to present it. Python is great at many things but there are other languages that outperform it in certain areas so don't try to sell Python into situations that it may not perform the best at.
So basically create a base standard application for Python and data science specific applications with many commas. That's what we decided to do. We had actually two different supported Python paths. There was the Python path of creating an API with Flask and a lot of people in the company really liked that but the data science people had much different needs.
Instead of trying to make them use the other one, the standard one, we just split off and then added all of the other things that they needed. Mini, Conda, some of the other. I'm not a data scientist so I remember installing packages for them that's about it. So we created use cases for people if the use case was big enough. Like if
there was a big enough segment of the engineers that needed it we would create a specialized one for them hence the data science specific one. I just mentioned this but same thing with like when I said creating the static analysis unit test provided out of box experiments experience with sensible defaults. So the project whenever you run it, it should work. The static
analysis should work with you know alerting on enough things. Like whenever I use pilot personally I turn off like the refactor or the conventional ones because while they are useful I don't need to fail a build over them. But if I have a missing import and that comes up as an error then yes I would like to fail the build over that. So that is what I consider a sensible default. I very clearly
document how they can use this or turn this back on or make it more clear but I with sensible defaults I just only go with what really in my mind mattered. And then at the same thing as I mentioned provide everything unit test. Documentation was the one that people really liked because their
products were already set up with Sphinx ready to go their flask apps and it already used like the Sphinx flask web plugin so their project automatically generated documentation for them as long as they put the doc strings in. If you help people with their documentation and you give them a place to put it they will actually do it. But I've learned and if you've ever seen some of my older talks if you don't people don't
write docs. I have a whole line of talks on documentation about that. So another really good one for you to do whenever I did when I was building the archetype is create good documentation around not only the the process like how to use it but also why you would want to use it and why
you chose to use things. So as you can imagine if I'm creating an entire python ecosystem I have to think about what package manager am I going to use pip am I going to use pipenv am I going to use poetry like what am I going to use am I going to use pip tools there's so many different things. So you need to create a rationale of your decisions. So not only do you document the use of the archetype how to use it how someone
getting started guide. Document all the known bugs and limitations because there will be some like you're there's going to be gaps and things if you know it has a bug or an issue document it let people know that it's going to be a problem. Rationalize the why you chose technologies. I have for everything I chose between using pytest for the unit test using pilot for the static analysis
we use pipenv for all dependency management and because of the we really like the lock file and stuff we used flask I used a couple of other different libraries inside of the base application but everything that I chose I wrote very specifically not only why did I chose it but I also wrote all of their
competitors so under flask there was Django and tornado and I wrote not only that these were options but why I chose not to use them because one as you can tell I'm not working there anymore but that product is still in use so if anybody ever needs to know why like why did I make this choice they can
go back and check my documentation and it explains at the time that you know past mason wrote it what he was thinking about and I also like to develop the doc right about the development journey there's like a little mini blog in the documents for this project of like I got stuck on something for a week and learned a very valuable lesson about dependency resolution and I wrote it all out and I wrote
out why I chose it and why I made these why this section of code exists what I was thinking when I was going through it because again as you can see I no longer work for there for uh verbo anymore but people still use it so it's it's setting up the person who's going to inherit your code for success um don't try to solve try don't use I
made my grammar span don't use python to try to solve uh every case oh wow I can't even don't trying to solve every python use case with one tool okay that I remember what that is now so what you need to do is yes flask is great but I had someone come up to me with with a request for using Django and they were going to use some database stuff and
they had a really good use case for it and what I did was I made sure that whenever I created all of the sections when I created when I put it all together I made it very easy to easy to take out uh certain technologies and replace them it would be easy to replace uh pytest with say unit test if you wanted to
um or replace flask with Django don't force people to use tools if they have a good use case for using a different one make it very easy make make the interfaces very abstract where you could easily remove the pieces and put in a new piece in we had someone use Django within the first couple of weeks of me releasing it and they complemented on how easy it was to just take out flask and put in
Django because the way the project was structured the way that uh the way that it integrated with the static analysis and the way the unit test yeah they had to change a little bit of the code but it was not ingrained in so deep that it was impossible to change it um and then another really big one because at the time that we were doing this we were that I was building this at Verbo we were discussing uh our open source
strategy and our open source paths um use as few internal or proprietary tools as possible um one this the the closer you can stay to vanilla open source projects um the easier it's going to be for you to upgrade things I have stories from my past that I could easily tell in another talk about
about dependency nightmares and the horrors of upgrading things that are 15 years past due um and that happened because we got locked into internal tooling um so don't don't do that it also it makes it way easier to open source later if you don't have anything internal one of the biggest boundaries you will face when you try to open source something especially from a very large company is
are there any company secrets is there any company magic that is in here and if you've used nothing but internal stuff and then the code itself doesn't really deal with those secrets it's very becomes very easy to open source these things so try to use as few internal or proprietary tools as possible it will not always be possible there were a couple things in my archetype that were very custom to our
cicd pipeline but it was very easy to take those out by again by creating well-defined interfaces for us to be able to replace things we were able to pull out the internal proprietary tools very easily so this is a weird so at the time that i was doing this this is
just part of the story um we were working on the basically the version two of the internal pass um for those of you that are paths uh nerd paths nerds or do dev op stuff our initial version of the paths was built using mesos and marathon as our container orchestrator and we were migrating into what into nomad which is a hash core product so verb verbose version two of the
internal pass was being built at the same time that i was building the python support um and what i was able to do with this and i i don't know to this day like at the time this was a good decision for me this made sense for me some people may disagree i it was it was it was a toss-up in the air
the python archetype was only going to support version two as someone who was on the pass team who was actively trying to migrate people onto the new better more advanced system we decided to use uh the python archetype as kind of a carrot and stick kind of thing where we could lead people into the new pass by only allowing them to do it on version two
now if you knew anything about the past it was actually relatively easy to port it over to version one but we didn't say that um so we allow as we were building it i was building concurrently with the my team as they were building the paths and i was helping with that i was also building this python archetype we were going to as i said we're going to use it to entice um
this was really good because i could use this to take advantage of new features in the paths and new things that we were trying to do um and people got excited about it because it was things that you couldn't normally do in the past system um however this was also bad because i became very heavily dependent on the past development timeline it took me six months to build this archetype
in reality it should have only taken me two or three but because i constantly kept getting stuck behind the development of the paths whenever they would have an outage or if at the time they were building this past they were still responsible for version one so if there were major outages on version one like all development time got lost so i got stuck behind it and also as
people were testing it and they found errors in the past it was very difficult to distinguish an error between what was an error with my python project and what was the error with the new platform so the reason i bring this up is because this was both a success and a failure at the same time um it was a success because it did
work to pull people over to the new version people actively migrated into python they really liked it um but at the same time it did leave a sour taste in a few people's mouths because the failures that were associated either with my code which i'm not gonna say my code was flawless there were times that i failed but at the same time there were also times that the past failed it kind of made it a push and pull so
um if you're i guess with this one the lesson to be learned from this one is if you're trying to introduce python in your ecosystem and say you're in a major devops change that maybe you're going from you know magic vm to kubernetes style deployments and they're building out that stuff tying it to be it being released on kubernetes could be a success for you
because it could also backfire on you so just be weary that um it will be difficult for end users to differentiate the difference between a failure of the paths or a failure of your actual application that you're building so some yes so some testing that uh some things for testing that i learned um
find yourself an empowered group of beta testers so uh they will help you evangelize later so i had a couple of customers what we called customers they were not really customers um they were internal people that were very excited about this uh application about about using python so they became my beta testers every time i released a new version they were the
ones that would update their stuff and actually some of them were were kind of um were kind of brave enough to run this in production uh when it in my mind i wouldn't have they were they were that confident and they loved it that much they ran some of it in production before the internal paths was even ready which led to a they were some like some
ancillary services that weren't terribly vital but it was really good because it helped us find bugs um you will need to find people to test your stuff because after developing it for six months i knew every happy path through it and i started to become like blinder i had blinders on regarding um regarding what was going on these
first people or first customers uh will actually attempt to use it in production and uh it'll make your heart squeamish a little bit because you're like oh it's not ready but they do it and it's it's fun um don't become upset or by the negative feedback or bug reports it's really easy for us to like sometimes take things personally when it comes to building these kind of things because we want it to
succeed so badly because we're we're so invested in python um the negative feedback or the bug reports is more often than not not a criticism of python and not even really a criticism of you it's just that what they're trying to use how they're trying to use your product is not fitting their needs take this feedback adjust what you're doing to fit their needs and they'll
love it even more so a couple of evangelism dues that i would definitely recommend doing if you want to evangelize not even the product so this is kind of what i did um ad verbo is demonstrate the flexibility of python let people know
uh how easy it is to just write something like like like bang out an application or something and show it show that it both it's good for apis good for data science maybe it's good for you know log processing and stuff like that show all of the different things that i can do and people will come to love what the product what the what the language does and they
will want to adopt it um rewrite existing applications that are considered troublesome or complex in python if you have old languages or old applications that are always going down or you're constantly having to fix them because they're just unstable or they're just overly complex try writing them in python um i have found many times that whenever i rewrite
complex c or ruby applications in python they become less complex just because of the nature of the language um so by doing this instead of you what you can do say with your manager is instead of patching this for the 10 billionth time can i try just rewriting it really quick can i can i just get like a sprint to see if i can replace this
application or at least get a proof of concept of this application in python running you know hopefully at the same performance level um and it's easier to understand it's easier to maintain because maintainability is one of the big things especially when you're in like a devops or an sre thing um write new applications or features in python if you're adding a new microservice or a new api or something
pitch the idea that hey let's just try it in python we have this you know we've done everything we've done so far golang or ruby or something let's try it in python um and just see how much easier it is if we don't like it we can always go back and rewrite it uh but let's just give it a shot let me try it um you'd be surprised how often people are willing to let people just go and try something on their muse you
know managers are meant to like you know they're meant to trust us they they have to trust that we know what we're doing and we know what's best for the company um and i'm not saying python is better or worse than any specific language but you know we we as pythonistas know how easy it is to maintain python and in reality the ease of maintainability of a programming language of a source
code is more important than almost anything else um yes performance is is great and all that uh we can get very close to that with python but like if i can't maintain it and it becomes unruly then it becomes a black box and then it's its own set of problems um be the temporary solution uh this is kind of what i consider kind of a sneaky way of
of showing the powers of python but it does work i i may have done it once or twice um if there's an outage or something's going wrong or you need to like you need to write a tool or a piece of code or an app really really fast just say okay i know i like i know i can write this in python really quickly let's go ahead and just write it really really fast and you'd be
surprised how often those remain in production um as my ex boss used to joke with us um and i used to laugh at it but then i realized it wasn't really a joke and it kind of makes me sad um there is no discernible difference between a proof of concept in production software um i have a whole story about that that if you want i can
i can tell you about it later um where one of my uh one of my test pieces of code made it into production i'm still upset about that um some evangelism evangelism don'ts when you're trying to evangelize python or anything um don't say that language sucks you should use python or you should use x um as we as pythonistas know we're
people are very protective of their language they're very opinionated when they come to the language people don't write in a certain language because they don't love it like we love python that's why we choose to write python so if you come off confrontational from the get-go not going to be a good you're not going to win anybody's affection all
you're going to do is you're going to put not only a negative connotation around python you're going to put a negative connotation around the python community which is which is honestly the i would say some of the work the bigger damage or the worst damage you can do because the python community is amazing hence all of us being here um so just don't do it don't don't come off adversarial with this stuff it really doesn't work out
don't try to use python to solve problems that python doesn't handle well if you need a super high performant multi-threaded thing that behaves the level of c and is really really uh you know really really fast and really really high performant you know amazing amount of cores maybe python's not the best thing for that
it might be but maybe it's not maybe golang and c might work a little bit better there um whenever people see things fail they tend to blame it maybe on the language itself so and it's really if if if you put python in a situation that it's not equipped to run or do as better than other languages and it fails people blame the language when in reality
it's not the language's fault it's actually your fault for put for picking the wrong tool um i don't try to screw in screws in my wall with uh with a level it just doesn't work like you can't do it so don't do that it's a really bad way to give people a negative impression of a language right off the bat and
and those impressions stick um don't be overbearing if someone isn't interested in using python right now that's okay don't don't be a don't be like a pusher and constantly trying to push it continue to do what you're doing continue to build cool tools and stuff continue to show off some of the neat little things of python and eventually you may change their mind but if you don't that's fine too
it's totally fine for not everybody to write python um the world couldn't exist if we didn't have all these programming languages what makes computer programming and software engineering such a fascinating field to study so don't be overbearing bring it up every now and then but you know if you become annoying then it's not it's not going to go over well so that's pretty much my story
uh the results that i can say that i saw from this are within the first month 80 applications within side of the uh within side of the ecosystem were using the new archetype in production so there was a demand for python whether or not people were openly saying it and there was a small group that was
people did want it and then by other people showing other people in the company it kind of began to grow um other people also then started using my development journey documentation to start building support for golang so not only did i influence you know people using python i started influencing other languages being supported within the company through this so
proper evangelism of a good project and document proper documentation all this can actually help support the evangelism of other projects you can support golang and you can support other things it's all a harmonious system and we all live very well together so that's that's my story like i said this is a very anecdotal story of just of my experience inside of the
industry um thank you for uh tuning in today feel free to tweet me uh if you have any questions i'm at masonnegger on twitter you can also message me in the discord i will be happily happy there to discuss anything uh regarding this talk or just anything in general i like talking to people uh and if you like listening to me present and stuff i i do a live stream
at one o'clock on tuesdays feel free to come and see me and if that is everything then i will turn it back over to our moderator