There’s a Snake in the Birdhouse!
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| 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 | 10.5446/50091 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Active contour modelActive contour modelType theoryComputer configurationBuildingXMLUMLMeeting/Interview
00:32
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
10:11
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
19:51
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
29:31
SyntaxbaumActive contour modelComputer animationMeeting/Interview
Transcript: English(auto-generated)
00:09
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
00:24
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,
00:46
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
01:01
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
01:21
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
01:46
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
02:06
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
02:24
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
02:43
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
03:03
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
03:20
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
03:42
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
04:02
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
04:22
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
04:40
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
05:00
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
05:22
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,
05:44
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
06:01
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
06:21
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
06:44
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
07:02
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
07:23
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
07:41
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
08:03
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
08:22
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
08:42
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
09:01
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
09:21
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
09:40
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.
10:02
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.
10:21
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
10:42
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
11:02
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
11:22
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
11:40
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
12:02
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
12:20
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
12:42
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
13:03
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
13:24
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
13:41
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
14:01
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
14:22
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
14:42
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
15:00
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
15:22
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
15:43
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
16:03
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
16:23
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
16:43
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
17:02
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
17:24
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
17:41
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
18:03
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
18:21
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
18:43
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
19:03
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
19:20
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
19:41
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
20:01
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
20:20
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
20:41
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
21:00
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
21:21
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
21:43
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
22:04
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
22:21
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
22:41
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
23:01
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
23:20
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
23:42
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
24:02
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
24:21
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
24:43
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
25:03
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
25:23
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
25:44
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
26:00
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
26:22
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
26:40
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
27:02
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
27:20
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
27:42
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
28:03
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
28:20
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
28:41
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
29:02
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
29:21
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