Quick, name the three most advanced engineering organizations you can think of.
Maybe an aerospace company such as SpaceX or Boeing came to mind.
Maybe you thought about CERN and the LHC.
But in terms of bespoke engineering capabilities, you should certainly put the F1 race teams on your list.
These organizations appear as 20 or 30 people on a race day shown on TV.
But in fact, the number of people back at the home base doing the engineering work can be well over 500 employees.
Almost every tiny part you see on these cars, as well as the tools to maintain them, are custom built.
The engineering problems solved are immense.
Would it surprise you to know that Python is playing a major role here?
On this episode, you'll meet Joe Borg, who helped pioneer Python's adoption at several F1 teams.
This is Talk Python to Me, episode 296, recorded November 16th, 2020.
Wait, wait, wait, wait.
Normally, I'd play a little guitar riff right here to kick off the episode.
But this episode is about racing and race cars.
So let's kick it off with a different kind of instrument and note.
Let's jump into a 2017 Indy Pro Mazda.
The furlap around the storied Brands Hatch circuit.
And let the engine notes be the music.
The furlap around the storied Brands Hatch circuit.
Welcome to Talk Python to Me.
A weekly podcast on Python.
The language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
And keep up with the show and listen to past episodes at
Talk Python.fm and follow the show on Twitter via @talkpython.
This episode is brought to you by Linode and Talk Python Training.
Please check out the offers during their segments.
It really helps support the show.
At Talk Python, we run a bunch of web apps and web APIs.
These power the training courses as well as the mobile apps on iOS and Android.
If I had to build these from scratch again today, there's no doubt which framework I would use.
It's FastAPI.
To me, FastAPI is the embodiment of modern Python and modern APIs.
You have beautiful usage of type annotations.
You have model binding and validation with Pydantic.
And you have first class async and await support.
If you're building or rebuilding a web app, you owe it to yourself to check out our newest course.
modern APIs with FastAPI over at Talk Python Training.
You have a first course in a series we're building on FastAPI.
And for just $39, it'll take you from interested to production with FastAPI.
To learn more and get started today, just visit talkpython.fm/fastapi or click the link in your podcast player show notes.
Joe, welcome to Talk Python to me.
Joe Pyshko: Thank you.
Nice to be here.
Oh, man.
It's exciting to have you here.
I get to come back to one of my favorite topics, racing, which is always cool.
And we're going to hit the peak of racing and engineering, I think, with F1 here.
Joe Pyshko: I think so.
I probably shouldn't admit this is an F1 guy, but I've always kind of preferred WEC.
But F1 certainly up there with the high performance.
Joe Pyshko: Sating.
So the world endurance champion cars, yeah, like Ferraris and stuff like that, right?
Joe Pyshko: Exactly.
All the Porsches, Toyota, I think are the biggest one-store racing in it.
Joe Pyshko: Yeah, yeah.
Well, now that you've stepped away, I got a little distance between F1, but you work for
two different F1 teams doing some really neat stuff with Python, and we're going to dig into
that.
And I'm super excited about it.
Before we get to that, though, let's just start with your story.
How did you get into programming and what brought you to Python?
Joe Pyshko: I've always been kind of a techie guy since I was a young,
young kid.
And my dad was doing a university course when I was like five or six, just about young enough
to remember.
He got a computer as part of the course and sort of, I was introduced at quite a young age.
It was just, it wasn't anything special at that point.
It was Windows 95 or whatever.
Showing my age there, I guess.
I don't know which way.
Joe Pyshko: Windows 95 was kind of special.
Joe Pyshko: Yeah.
Joe Pyshko: I think Windows 95, like it was the first operating system that really felt like
welcoming and good.
Joe Pyshko: I mean, I think you could debate about some of the early Mac ones, but the
early Mac ones were like super bizarre in some ways.
And Windows 3, one, like that was a neat time actually.
Joe Pyshko: Yeah.
Oddly, I was introduced to Windows 3.1 after 95 because of school, which seems like a weird
order to do it in.
Joe Pyshko: What is this thing?
Joe Pyshko: I sort of vaguely remember that though with my dad choosing the themes because
I think it came with plus or whatever it was called, the big theme pack on Windows 95.
And we spent more time doing that than about anything else.
But then he started showing me how Excel works and how you can do not just the kind of conditions
on each cell, but then into VB and stuff like that.
So that's how the seed kind of got planted.
Joe Pyshko: I never went to university, but I did an apprenticeship with British Telecom,
quite big in the UK with that kind of thing.
And I actually did network engineering for a few years there and got my qualification.
I think that would be an associate's degree in the US.
Joe Pyshko: Yeah.
At that time, there's probably not a lot of programming in the network engineering, but
there's a lot of scripting and automation.
So it's like on the cusp of programming, right?
Joe Pyshko: Exactly.
Joe Pyshko: Okay.
Joe Pyshko: So I much preferred that to sit manually subnetting stuff for tests, et cetera.
Like it was much nicer to be doing mostly like it was just scripts for provisioning routers
and things like that.
And we had a few systems internally that were, that we wrote because the commercial stuff just
wasn't very suited for us.
And then I got quite a lucky break with my, the first team I worked for.
Dropped in for an interview, which took several hours, which I kind of assume was a good thing.
Joe Pyshko: And they haven't kicked me out yet.
Maybe I'm here.
Joe Pyshko: Exactly.
Which was, it wasn't really a technical interview at all.
It was more, how would you approach this on a high level?
And I think at the time there wasn't really a developer focus for especially the aerodynamics
side in Formula One.
So literally just saying, you know, I'd have a web front end for all of the users and I'd
store stuff in a database and I'd save things on a, on a network file share, et cetera.
That was enough to, to pique an interest.
Joe Pyshko: Cool.
And did you learn Python there?
Joe Pyshko: Yeah.
So it was, I think I had a few months in between interviewing there and then actually starting
the job.
So I started learning at home.
I was already a Linux user.
In my high school, we had a Linux user group, which especially in the UK, I think was a very
rare thing.
It just so happened that one of the IT guys was into it and a couple of the six formers
were into it.
It was Fedora Core One.
I think at that time had just come out.
Yeah.
And that's what we were all in.
We'd found some old computers that might be being dropped or whatever.
And we were allowed to reprovision them with, with Fedora Core One and get them a new lease
of life as it were.
So I'd, I'd kind of got...
Yeah.
They were probably blazing.
They probably had thrown away because they were too slow to run.
Exactly.
And they were blazing, right?
Joe Pyshko: Yeah.
It was nice.
We did a couple of like LAN parties.
I can't remember what game.
Probably some terrible free game that no one actually played in real life.
But just to prove that we could get them running on the network.
I had a bit of background of sort of scripting and like provisioning, especially Linux nodes
at that point.
So the biggest thing was learning Python.
And so I literally sat down with Python for dummies at that point and just started basically.
Yeah.
Cool.
Neat place to like start this new venture and you can learn this new language and kind
of like grow into this whole tech world that you were jumping into, right?
Like sort of, we'll start with almost IT, but like, let's go farther.
Exactly.
I'd always sort of wanted to be a software developer.
I just needed that kind of prod, I think, to focus on that rather than networking and IT.
Yeah.
I had a similar experience.
You know, I feel like in the abstract, before you get there, like being a software developer
is this big daunting thing and it's, there's like so much to know and you don't really know
where to go with it.
But then someone comes to you and says, could you do this one thing?
Could you make this happen with programming?
Like, I could do that one thing.
Sure.
I can do that.
I'm not a programmer, but that I can do.
Let me work on that for a while.
And like, eventually you're like, wait a minute, I could do a lot of stuff.
I'm a programmer.
How do I get here?
Especially with the first job was mostly converting to start with anyway, the first kind of six
months was converting existing stuff into Python, mostly Bash at the time.
So you've already got at that point, you're not focused massively on sort of architectural.
Right, right.
Side of things more just getting comfortable with Python, trying to do everything in a
Pythonic way.
So obviously with Bash, there's going to be a lot of repeated code when you're trying
to modularize that.
And yeah, that was a really nice way to kind of settle in, I think.
Yeah.
Cool.
So I mentioned you had stepped a little bit away from F1 these days.
So what are you doing now?
So now I work for Canonical.
People, if they don't know the company Canonical, probably have heard of Ubuntu.
So Canonical are the kind of corporation that back Ubuntu.
And yeah, I'm working for the Kubernetes team.
We work on a couple of projects.
One is what we call charm Kubernetes, which is a kind of very modular Kubernetes distribution.
You can sort of pick and choose how you want your cluster to look and you're pick and choose
out all the different components of how you want to put it together.
That's all done in Python.
So we have these, the individual components in our distribution are called charms and they're
literally blocks of Python code to define what to do.
what to do if it bumps into another component.
If one of those components go away, how to react to that, et cetera.
So imagine something like Terraform, but with a constant controller that's watching over the
infrastructure.
Yeah.
That sounds super cool.
It is nice.
We're currently working on a new revision of the actual Python framework that's written
in to basically make it more Pythonic.
It was perhaps a bit more kind of scripty before.
So that's, we're quite excited about that.
I think that's going to be releasing in a few months.
Nice.
What's the relationship of that and OpenStack?
Is there any?
I used to work for the OpenStack team as a field software engineer.
So at that time I was sort of going to customers and helping them either decide to go down the
OpenStack route or not.
OpenStack as well through Canonical is delivered in the same way through what we call charms.
So all the individual components of OpenStack basically defined in Python and then connected
together with what we call interfaces, which again is sort of Python defined functions of
executed at the time that your infrastructure comes up and then mutates.
Nice.
So a lot of people listening out there, I would imagine everyone has heard of Kubernetes.
Yeah.
And probably Docker as well.
Maybe less degree OpenStack.
Yeah.
You know, I've had some guys from OpenStack on before, Flavio.
Mm-hmm.
But maybe just give us the elevator pitch of like Kubernetes, Docker, and then what this thing
that you guys are building, like why is that better than just like random Kubernetes or your
Docker compose or something like that?
Sure.
So a kind of on a single machine level, you have Docker and Docker is basically just there
to run containers.
You can have either a single executable in that container or multiple, but obviously there's
an amount of isolation that goes on with that container, namely network resource and disk
base.
If you want to orchestrate something a bit bigger and especially across several nodes, perhaps even
several networks, you would use Kubernetes.
Kubernetes is basically just there to decide when and where to place your Docker, in this
case containers, it can be others, but we'll keep it Docker at this point.
And then also what to do if there's any issue in either provisioning those or once they've
started running.
So it's just Kubernetes is sat there to basically ensure that what you've asked for remains the
case.
So if you've asked for five Nginx servers inside Docker to keep them running and if one of them
fails to replace it with a new one.
Yeah.
And Kubernetes is pretty good for like rolling out new versions, right?
It can do basically zero downtime deployments.
Yeah, exactly.
So for example, if I had like a web app, I'll have the actual, let's say in this case, the
Django app and I release a new version of that.
I can actually use Kubernetes even to start rolling out the new version of Django app and then get
the, for example, Nginx load balancer to start firing 10% of the traffic at the new instance of our web app.
And if there's a problem, it can just remove that part of our Nginx application.
Sorry, our Django application and then continue how it used to be.
Or indeed, if it's successful, we can keep changing that 10% to 100 in time.
So it's very flexible like that.
So you've kind of come back to the software side of where you started with like network engineering, right?
Yes.
There's definitely been quite a few instances where I've had to sit and remember how to work out subnets by hand again, which is something that I was hoping never to use again.
But certainly, certainly appreciating that I had to before.
Yeah, absolutely.
All right.
So let's talk about this, your Python journey through a couple of F1 teams.
But I do want to set the stage just by setting the, giving people a sense of the scale, because when I learned about F1, it seemed to me like, okay, well, here's a, there's like a race organization and you watch it on TV or you watch it somehow.
You'll see like, there's a team of 20 people in the little pit garage and the pit wall there.
And you're like, okay, well, these are the people that do the racing and the race car.
And they talk about engineering.
But then as you pay more attention, you're like, oh, and then this is where they actually went back and redesigned the carbon fiber tub so that they could like change some setting.
And then they redid this, you know, like you start to realize like there's a huge engineering, like super advanced engineering organization that looks almost like an aerospace company, maybe.
Yeah, these days, aerodynamics is very much the biggest factor in Formula One.
And as you say, you watch the Formula One on the television, you maybe see, as you say, 20 engineers and mechanics sat either on the pit wall itself or in the garage ready to service the car.
But in reality, there's another 400 people, 500 people back at base who have been working on the tiniest details on that car to make sure that every bit of performance possible is being extracted.
These days, it's not uncommon to see aerodynamic departments alone with 100 people working in it, which, you know, is a large user base, you know, even for a fairly modest software company, I'd say.
Yeah, yeah, that's quite an incredible thing to realize just that many people are working on, you know, like you said, just the aerodynamics.
And that was the part that you were associated with most, right?
That's right. So I was a aerodynamic software engineer slash aerodynamic systems engineer, depending on who was giving me the title at the time.
So effectively, I was the main person writing software and sort of ensuring the quality of it for these aerodynamic departments.
It did bleed and especially in the second team into the vehicle dynamics department as well, because obviously what you're simulating, it's like shock springs, that kind of stuff.
Is that what that would be?
Exactly. Even usually nowadays, all of that is driven mostly by aero.
So even the suspension on the Formula One car isn't about having this.
It never was about having the smoothest ride, but it's mostly about keeping the car in the correct attitude for to exploit the aerodynamics.
So you'll see an F1. Yeah. And I guess it's probably worth also putting out, like you said aerodynamics are important.
It's an important part. It's it's an insanely important part.
And like you watch those cars go and it looks like slot cars, like those toy cars that had like literally a little peg that would stick them to the track.
Right. They just zoom, zoom, zoom, zoom. And it seems like impossible.
And that's because of all the aerodynamic force.
And you listen to them talk about it's like multiple times the weight of the car in aerodynamic force. Right.
Yeah. I would need to double check this, but I'm pretty sure around the time that I was there, you're talking 4000 kilos.
So four metric tons at the kind of 200 mile an hour mark.
I know I'm mixing metric and imperial, but at that kind of speed, it's in that ballpark of downforce.
So it's multiple times, maybe not quite an order of magnitude, but not far off in downforce.
Yeah. And obviously it's not too difficult to just do that in downforce, but you need to do that without adding a huge amount of drag to the car as well.
So the real research is right. No drag, no, no, no extra weight, not much extra weight, all those kinds of things. Yeah, it's exactly.
That's where you could just have a huge wing. Yes. Like a 747 on it. Right. It'd be fine.
Exactly. Massive angle of attack. It's something else worse.
And then it could only do. Yeah. And I get, yeah, there's also like some interesting history in Formula One.
Like one of the very, very cars didn't used to have these aerodynamics.
And in the early days, one of the first ones was called a fan car.
And it was this bizarre car where they put like a rubber skirt on the car and literally put a fan that just sucked the air out and just like it was like a vacuum to the surface.
And that that was around for a little while. So it was banned.
Yeah. But it was they actually withdrew it before it was officially banned.
There was some odd politics going on. Interestingly, the guy that designed that has just come out with a road car with the same system in place.
So if you want to, if you want to buy the experience that you can buy it now.
Amazing.
This portion of Talk Python to me is sponsored by Linode.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy and scale your modern applications faster and easier.
Whether you're developing a personal project or managing large workloads, you deserve simple, affordable and expensive.
Cloud computing solutions. As listeners of Talk Python to me, you'll get a $100 free credit.
You can find all the details at talkpython.fm/linode.
Linode has data centers around the world with the same simple and consistent pricing, regardless of location.
Just choose the data center that's nearest to your users.
You'll also receive 24/7/365 human support with no tiers or handoffs, regardless of your plan size.
You can choose shared and dedicated compute instances, or you can use your $100 in credit on S3 compatible object storage, managed Kubernetes clusters, and more.
If it runs on Linux, it runs on Linode.
If it runs on Linux, visit talkpython.fm/linode or click the link in your show notes, then click that create free account button to get started.
All right. So it's in this context of working in these really intense aerodynamic requirements that the cars have today that you started working in the first team that you work for.
At the time you were working for it, it was called Forced India.
That's right.
And now it's called Racing Point.
Yep.
If people listen to this episode next year, it's going to be called Austin Martin, I believe.
That's right.
Is that right?
Yeah.
Yeah. Okay.
So that group, and at least so far, has always been the pink car.
So that makes it pretty obvious, right?
All right.
So yeah, you said you started there and you had that interview.
Tell us about like, you showed up, there's a bunch of bash scripts.
Yeah.
Then what?
So then basically, the first job I had was to sit down and to convert as much of that into Python.
There was an aerodynamicist who had since moved on, who was kind of also interested in Python.
I'm not sure how he got interested in Python.
So he'd done a small amount of work, like a sort of proof of concept, as it were.
Yeah. Before we get too much of the details, let's take a step back and just like, what kind of problems were you solving?
Because I know a lot of people probably don't know like the standard workflow of aerodynamicists and so on, right?
Sure.
So effectively, the name of the game there is to allow aerodynamicists to draw parts CAD and then within a certain amount of time, be told whether that was a good thing or a bad thing.
So obviously, we can do that with a physical wind tunnel, which is how Formula One teams have been doing it for decades.
And then more recently, as technology has caught up, we can do that with simulations, which are called computational fluid dynamic simulations.
So when I think back to my math experiences, like basically the hardest math seemed to be around fluid dynamics.
So that sounds like there's a lot of computation.
There's a lot of a lot of things going on there.
It's not easy to do that kind of stuff, right?
Sure.
So like laminar flow, very basic flow is fairly easy to model.
It's when you start talking about the turbulence that goes around the car, which is what a lot of teams exploit, what all the teams exploit to really get a lot of that downforce.
And that's when you sort of get away from realized sort of mathematics into more sort of guesswork.
I guess it's come from lots of years of getting as close as possible to having something that's real, but it's still a bit of guesswork.
Right, right.
Okay.
So in this context, you showed up and you're working.
There's a bunch of bash scripts that like piece together like the CFD computational fluid dynamics pools and maybe data coming out of the wind tunnels.
And you're like bash scripts.
Come on.
Exactly.
Which is, it was very common.
Most of the guys that set the stuff up from university and that's how they did their projects at university.
Right.
Probably didn't come as developers, but probably came out of engineering disciplines.
Exactly.
Yeah.
So they had the same attitude from university, which was, we just need to get this done.
We know bash, which is perfectly fair enough.
The goals really were to get something that was a bit more reliable because you obviously you change a line in bash and you've got no real accountability for that change.
It could, if one part of this sort of pipeline fails, then the whole thing would fail.
So it needs to be made more robust.
And we wanted to start sharing code because it was, there was these mammoth bash files for each sort of discrete part of the process.
And can imagine trying to debug those things.
Or if you want to change something, you're like, oh, we really don't want to touch that part.
That part's bad.
There were days where we'd sit there just staring at thousands of lines of bash, trying to, trying to find, you know, very, very small problems.
Is there a debugger for bash?
I don't think, not that I've ever heard of.
So we were using Eclipse at the time, the IDE.
You had the theme, the bash theme, which helped a lot.
Yeah.
Just, just even for counting brackets.
It's syntactically correct.
It's sort of.
Yeah.
Exactly.
But I don't think there was specifically a debugger.
Yeah.
And not that I'm sure someone will send us a message in the show notes.
Like here's the debugger, but yeah, that it's not easy to work through those things.
Yeah.
We've done stuff with minus X, obviously to get a step-by-step printout of what was going on, which we had to resort to quite often.
But the level of, verbosity that you'd get back would be far too much for what you really needed that, you know, it would have just been a variable that hadn't been set correctly.
And yeah.
Yeah.
That take a day to debug.
Okay.
So you're going to convert these over into Python and you also wanted to share more code, started using databases, things like that.
Yep.
So there was already some use of a, SQL, my SQL in the first instance database that was being written to in order for an existing web app to be able to display mostly headline numbers could then be drilled down into.
So once you sort of change the part on the car, it would tell you the kind of effects that that had.
And so, yeah, it was about really getting more into the database than just, you know, summary, as it were things like we would need to produce images.
And that was all file name based to begin with, which is fine until you suddenly have a new variable, for example, on the, in the image.
And then suddenly your whole naming convention falls apart.
So it was basically just lots of little bringing it up to some grade of sort of, I guess, enterprise grade rather than the kind of university thesis grade that it was at.
Sure.
How did people interact with it?
It was basically like a website or some kind of GUI app or what was it?
Yeah, the biggest kind of the front page as it were, was a web app at the first company was all written in PHP.
And there was, there was an existing site when I started work there and sort of ended up doing quite a lot of modifications to that.
It was all static pages when I first started.
So trying to make them more interactive so that people didn't have to keep hitting refresh every sort of two minutes.
And there's a lot of image manipulation because you're talking about an entire car.
So we would make thousands of images per car, per simulation.
And to be able to browse those, you know, statically was not nice either.
You're literally loading a full image each time you click next or up or down or however you're trying to navigate.
So yeah, that was the kind of main entry point for someone.
If they wanted to drill down at that point, they would usually open some specialized application where you can basically open the 3D model of the car plus all of the simulation data.
So, you know, I'm sure people have seen like a picture, like a 3D model of a car in CAD.
Now imagine the actual aerodynamic simulation data on top of that and that you can turn on and off and choose how that's being depicted, etc.
Yeah.
And that just required quite a lot of hardware to do.
So that was, that was something that was sort of saved for when you really needed to drill down.
Yeah, it's still, it sounds like a really empowering thing, right?
I mean, instead of doing physical testing and building physical parts, plugging them into a wind tunnel.
Exactly.
All right.
You can piece these tools together and dream them up.
See what the math says.
Exactly.
And look at them, right?
It really streamlined.
You know, if you think about it for the wind tunnel, the part would have to be designed in CAD.
It would then have to be effectively 3D printed, not in the way that your home 3D printer would do, but it's a similar concept that would then have to go and be finished.
Because if it was the home printer, like the 150 mile an hour wind would just blow it apart, right?
Yeah.
And all the kind of small defects you get kind of render anything you've done useless as well, sadly.
Okay.
And then these model parts have to be finished by hand as well.
So they were a team of probably 10 or 20 people literally just finishing small plastic-ish parts.
And then the aerodynamicists would have to convince their team leader that this warranted some time in the wind tunnel.
So then that part would be physically has to then be affixed to the model in the wind tunnel.
That run is then performed.
And then you get the data from that.
Whereas with the CFD approach, computer simulation approach, at that point, just making a change in CAD and then getting the result back, it would still take a few hours to run.
But in comparison for the time and labor that goes into the physical parts, it's very empowering.
As you say, it's a much quicker.
It's way better.
Yeah.
What kind of compute did you guys have?
Just like machines you could send it off to?
Or did you have like grid computing or like high end clusters or?
So the Formula One teams tend to be quite, I say, paranoid is probably the word that comes to mind when it comes to compute.
So there is no cloud computing done, which I think is a shame because we could really exploit that.
So the teams have physical clusters on site due to a quirk in the rules.
Teams had very specific clusters at the time as well.
So there were limits on how many floating point operations we could perform within a time.
No way.
So I mean, I'm sure a lot of people don't know.
There's actual limits on how much time you're allowed to do all sorts of testing.
How much wind tunnel time are you allowed to spend per year?
How much time on a test track?
That's right.
All these different things are highly, highly regulated, but down to the down to the floating point operation?
Literally.
And as I'm sure some people are aware, like my gosh, modern CPUs tend to do multiple floating point operations per clock cycle.
But the simulation code that we were using, which most teams use because it was written quite a while ago, will only exploit a single.
Some I think would exploit two.
But it meant that the number that you were giving to the regulating body, it had to be pegged to the CPU.
If your CPUs were performing eight floating point operations per cycle, that's what you had to tell the governing body.
So the most important thing wasn't necessarily the speed.
It was like your resource was number of CPU operations in a sense.
Yeah, exactly.
And like, how do you minimize that?
Okay.
And literally AMD sponsored one of the teams in the early days of this rule.
And they pulled an old, I can't remember which, I think it was called the bulldozer spec at the time.
If I recall, it was an old Opteron, I think.
And literally.
Yeah, yeah.
It was one of the old server, server things from AMD server CPUs.
Uh huh.
So nothing special at all off the shelf.
It would be almost free because they were trying to get rid of them.
And they basically sort of through hardware killed off all but one of those floating point operations per cycle.
And then went, oh, we've got a perfect Formula One chip here.
And then sold it for obscene amounts of money to the teams.
So most teams were running, we're running with those for a while.
That's since been rectified, which is good to see.
But yeah, it was, I'm trying to recall how many, we probably had several thousand cores.
Each job would run on a few hundred cores spread across several machines, several hundred gigabytes of memory, if not getting into the terabytes of memory per simulation.
Yeah.
So yeah, they were quite hefty, quite hefty jobs.
And they would take anything between four to eight hours to process depending on the size of the, of the model that you were using.
I'm just still like blown away that that's the metric you got to worry about is like the number of CPU operations.
Yes.
It really just must drive a lot of non-intuitive or non-obvious decisions or choices or trade-offs, right?
Like, oh, this part, we could probably do this part in Python.
Oh, but there's a lot of operations there.
We're going to write that in assembly or something weird like that, right?
So we were quite lucky in that sense because the actual simulation software itself, we bought in.
And so at that point we just said, this is what it says on the box.
So we'll assume this is correct.
All right.
Although things like any like time loading the data in was a big cost because that was on the clock effectively.
As soon as the job started, the, the clock's running.
So the actual kind of the software itself, how many can some, how many clock cycles it was consuming?
Wasn't a big issue.
It was just about getting stuff done as quickly as possible.
Like the isn't simulation time.
So, right.
You know, if, if you have a bit of Python sat there loading some artifact that's taking five minutes, that's a big problem.
So anything that was blocking, we had to pay real special attention to.
Oh, how interesting.
That's such an interesting constraint.
Maybe give us a sense of some of like the,
some of the libraries and stuff that you were using there.
I mean, before you answer, I just, one of the things that never, and you know, never ends to blow me away.
Blown away by, I guess I should get it out that way is on one hand, things feel so different.
So I think that's a high-end custom engineering company that is a high-end custom engineering company that is F1 racing teams compared to like a grocery store, a software team that optimizes like what offers do we send to people?
You look at the tools, you look at some of the programming.
You look at some of the programming.
It sounds real similar a lot of the times, right?
Yeah.
Even though like the special sauce is absolutely different.
Internally, it looks a lot of similar.
All we were really doing was gluing bits of existing software together and then trying to kind of optimize around that.
So we use like NumPy, for example, for handling all of these, all the numerical data that comes in after the simulation and just trying to, for example, average over it.
So these would...
One thing that is really, I was wondering about when I saw you sort of make a note of this was if you had terabytes of data.
Yeah.
How do you load that up?
Right?
Like, where does that go?
We're using some sort of distributed computing or like processing it in little parts.
I mean, Dask might make it work, right?
Across different machines.
But what was the story there?
So we had dedicated infrastructure for loading the cases.
So these things would have around a terabyte of RAM each.
And so we would load, obviously, the jobs that had come off the distributed, like actual compute side of the cluster.
It would then write out a, let's say, terabyte file.
They then were loaded on to another node, which isn't on the regulation clock, as it were, because we finished the actual compute part, the actual simulation part.
And then we can start actually decimating this data and getting what we want out of it.
So this bit can take a bit longer.
We obviously still want it to be performant because we don't want stuff waiting in the queue.
So these were huge nodes, the really fancy Nvidia graphics cards in them, pretty big CPUs as well.
But the RAM was the big thing.
I mean, especially back in the early 2010s, like a terabyte of RAM was pretty serious.
And, you know, far bigger than the hard disk space.
And the power supply for all these computers, right?
Like there must have been like a big, huge power system.
Even though the cooling in what was a fairly small server room was huge because these things are just lit up all the time.
Okay.
So you had machines that were like heavy enough that could just basically load it up anyway.
Yeah.
All onto one node.
And then we would use a mixture of some open source applications that are designed to load in these sort of big files.
PowerView is the kind of main one.
We replaced some commercial software with PowerView because PowerView was free and open source.
So we could actually a develop against it and be not have to pay for the commercial side of it.
And we did actually pay them for support, which ended up being really nice, actually.
And so, yeah, we would use software like that as well as some Python libraries like NumPy and Matplotlib and use these two in combination to make lots of images of the car, lots of plots.
Because, of course, we need to see as many plots as possible.
Yeah.
And sort of try and average out a lot of the data into something meaningful because no one can sit back and look at a terabyte of data.
We need to pull out a kind of headlines from that, but be average over a lot of that data just to get meaningful numbers.
Well, it sounds like a really interesting thing that you guys put together there.
So you did that for a couple of years or five years and then you moved on to another team who decides to change its name.
Yes.
Because that's your history, apparently.
To Scuderia Toro Rosso, which is now AlphaTauri.
Yes, that's right.
Is that right?
So it's the Red Bull sister team.
Exactly.
So Toro Rosso is just Red Bull in Italian, which was nice because I got to go to Italy quite a lot.
So, yeah, I spent quite a few years at Force India and we did some great work there.
I worked with some really, really good people.
And we spent a long time converting what was there into a much more sort of streamlined and enterprise.
I keep using that word process.
Did you look back at that time and just have like a lot of pride and like look at that transition?
Yes.
We helped them on the technical side of engineering there.
Definitely.
I think that there's still a great team there that are carrying that on.
You know, it wasn't a case of me leaving and it all stopped.
It's still very much all continuing.
They're still making big strides with stuff there.
So that's really nice to see.
And in fact, I think they've done a few of the rewrites that I was hoping to do there,
which is why I ended up going to Toro Rosso is because rewrote a lot of the bash into Python.
I really wanted to rewrite that PHP web app because kind of I've done as much as I could by slapping a kind of single page application on the top of an existing PHP site.
And I really wanted to actually use Django.
I'd made the proposal there to replace it with Django because we were already very invested with Python at that point.
So, yeah, the I got a phone call one night from someone at Toro Rosso.
So it's amazing how this works in Formula One.
Like there's a lot of churn between the teams.
So I got a call saying, oh, we heard that you've translated a lot of stuff from bash to Python.
We're looking to replace our processes as well.
Would you be interested?
I sort of said, well, yeah, I've been waiting for a while to get the go ahead to do this at Force India.
So I'll come and I'll try it here instead.
So, yeah.
Yeah, that's really cool.
What I think is really interesting about that transition is like you've got to bump up against all the challenges.
And, you know, you made a lot of progress at the first company, but it was still stuck in the kind of the way it was before.
And here's a chance to say, all right, if I could reinvent that world and do it the way I now know it should be done.
Exactly.
Like that was your chance here.
Right.
Which most people, I don't really think, get a chance to kind of put those two things side by side.
So what was that like?
Yeah, I agree.
I mean, I fully appreciate why Force India didn't just want to start everything from scratch because everything's much better than it was four years ago.
So why do we need to keep going?
So, yeah, it was it was really a good opportunity.
I really had been that sort of planning how I might do it from scratch in my head, especially facilitating Django.
Like at the time Django was becoming quite popular.
And I'd kind of got fed up with writing inline SQL in Python and PHP at that point.
It's not really great either in any place.
No, luckily it's everything's fairly sort of secure and tied down in that environment.
Very much air gapped.
There's no there's no Internet connectivity.
So no little Bobby tables.
Exactly.
Do you know that?
Yeah, exactly.
Yeah, yeah.
It would have to be an aerodynamicist doing it.
It would be interesting to see if they could put SQL injection into a CAD model.
That would be quite a feat.
Indeed.
So tell us about like when you had this perspective, this chance to kind of redo things.
Tell us tell us about that journey.
So, yeah, my main goal really was to kind of bring together both the web app side and the side that was running all of the simulation side.
So as we've said at 14 year, it was very much you had a bunch of code that was running these discrete steps through the cluster and then spat out some data at the end, which was then picked up by the web front end.
What I really wanted to do was make that much more of a single application, probably behemoth.
And to leverage a lot of the stuff that Django gave you like the ORM, for example, is a real interest from my perspective.
You know, having your database written out in code.
Yeah.
Or sometimes get a bad rap.
I did a bad rap, but I feel like 80% of the time it's absolutely like no, no contest.
Like it should just obviously be the thing used.
And every now and then it maybe it's not the right answer, but that's not the main case.
It's so nice to work with those things.
I agree.
Especially when you have a lot of relational data like we would have.
So, of course, we have an overarching object, which is the simulation you just run.
And that's connected to hundreds of discrete fields and rows all over different tables, which to manage in your mind, something that's not committable, as it were, is not nice.
Having it all nicely laid out in Python.
And of course, your Python linter can check that what you're doing is saying passing objects around on the face of it.
So, yeah, it makes that not just easier, but in my mind, a lot, a lot safer as well.
Yeah, there was some, I don't know where they got the data, if it's like some internal research or just internal keeping a record of how many bugs there were.
When I talked to Lucas Lange from his time at Facebook and Instagram, and they converted a whole bunch of stuff to have type hints, basically so the system could know what's going on.
And they said they dropped the number of bugs that they run into quite a bit down by just having that kind of how does this hang together type of analysis in there like you're talking about.
Yeah, I can definitely see that. Like the moment that type hinting became a first class citizen in Python, I was straight on it.
Because it does just, as you say, all the silly things that people do it.
I mean, not all of them, but it gets rid of a lot of the silly mistakes you make a lot more than you first think as well.
Yeah, many of them. Yeah, for sure. Yeah, I'm with you. It's fantastic.
Yeah, and the ORM is doing that for you on a database level. And it just means you don't have to keep creating DB connections in code all over the place.
If you've got part of your application that needs to access the database, it's just an object to Python's view.
So it just to me, it simplifies so much of that environment that I was very happy to use it.
Nice. So you rebuilt a lot of that workflow over that PHP sort of static site thing.
Exactly.
In Django. And that sounds like it was a really good experience, right? Like what was the contrast between like a PHP site and Django?
To me, I think PHP has moved on quite a lot now. At the time when I was using it, it was mostly just a templating language, or at least we were using it as such.
Right. In 2010, it probably was already not brand new at that point, right? It probably had been...
Exactly.
...around for a little while. So we're talking like 2005 PHP or something along those lines, right?
Probably, yes. So it...
Yeah, okay.
It was a massive difference. So it was all of the front end was defined effectively in PHP.
I then slapped on a bunch of JavaScript to try and make it a bit more of an SPA, but it never...
Obviously, that's... there's a limit to that.
I wanted to make this new sort of management site completely first class SPA, because when you're dealing with so many different objects on your webpage,
being updated constantly, the simulation is spitting out new data every few seconds.
And if you want to track that, you don't want to be sat there refreshing the page every couple of minutes.
Right. Yeah, it sounds super cool.
What JavaScript framework did you pick?
In the end, Durandal, which isn't that well known. The guy who wrote it now works at Microsoft and has...
I've heard of it, but I've never used it. Yeah.
So it's now... it's been sort of superseded by Aurelia.
I think of the guy's name. I think it's Eisenberg is that name?
Mm-hmm.
But just look up Aurelia.
Rob Eisenberg. Is that right?
That's the one. Yeah, exactly.
Yeah.
And the reason why I liked it is because it's not very intrusive. If you know JavaScript, you'll get along very well with Aurelia or Durandal, because it just looks like JavaScript.
You're just making observable variables effectively. Whereas we played around with Angular for a bit when it just felt like I was writing something completely new and didn't really want to spend time learning completely new world effectively.
Yeah, for sure. I had the same sort of feeling about Angular.
Yeah. So it was like, especially for what we were doing, I found it a great front end toolkit, honestly. And all the stuff I'd done at Force India, I'd written pretty much from scratch.
A lot of jQuery to Polyfill because we had a mix of Internet Explorer on the Windows machines and Firefox on all the Linux machines. But mostly it was all from scratch, which I didn't want to do again, because again, that has limitations pretty quickly.
Of course.
So we didn't use much of the Django templating itself. So we weren't creating that many static pages with Django. We were mostly using the views as an API server, and we would just serve up this SPA on first.
Right, just basically teach the views to return JSON and you're good.
Exactly.
Something like that.
Yeah.
Okay.
So one thing that you put in the notes here that I think is super interesting is that you had some of the views were like performance critical, and they were backed by CPI object.
Yes.
So what is this?
What is this?
Tell me about this.
So I'm trying to think precisely what it was doing.
It was basically just collecting a bunch of numbers and then either multiplying them together or doing some function on a bunch of numbers.
And yeah, that was taking too long for Python to do on its own. So we ended up basically writing that in C using py object. And then obviously, you can just import that.
Right, exactly.
You can use the code to do on your Django view, which is really, really nice. And it sped up the function massively. And that was a function that was called multiple times in a page load, which isn't the nicest thing to do, but it had to be done.
So like the page load speed was improved dramatically.
Absolutely.
I think that's a really interesting escape hatch because Python is so nice for so many things. But there are certain things where it's just kind of slow out, right? And a lot of the libraries that get used in those places like NumPy and whatnot, they actually just fall back to C.
Exactly.
Internally, you just don't have to think about it, right? But this ability to say, Oh, I'm going to rewrite this in C or in Rust or something just for this little tiny bit, like you don't have to write the whole thing in it. Just this, you know, 10 lines or 20 lines or whatever it is.
Yeah, and that's all it was. I think we wrote it once, piled it, shipped it. And then I think there's one alteration done a month later. And that was it. It just sat there for years. And we never touched it again.
Beautiful. Yeah, the reason it's so interesting to me is because I often think about this in the terms of like a data science computation, right around those tools. Sure, they would do but like in terms of Django, it's just interesting to see it there. It's cool.
Yeah, because we were using Django for pretty much everything except the actual driving of the simulations themselves. So we used Celery quite extensively for queuing and running micro tasks. So the simulations at this point, we're actually kicking off a bunch of Celery tasks to go and extract data, etc, etc.
etc, etc. So it was we had two very big, not quite as big as the nodes that I'd mentioned before, but two very big nodes running this Django app across the two of them. And just having Django manage all of that with the fact that we can just import the ORM to dump data into the database was really, really nice.
Sounds super cool. Another thing this time sounds like you got to displace was a little bit of MATLAB.
Yeah, so that's the sort of small work I did with the vehicle science side of things. Basically, I think any software developers job in F1 is either replacing Bash, Excel or MATLAB, because
Yeah, one of the people can replace one of the three pick one, right?
I did. Yeah, I managed to do all three, actually. Believe it or not, quite a few teams as of recently were running wind tunnels off out of Excel, which is I still whoever wrote the VB to make that work is insane and a genius at the same time.
Like it's a mad genius.
It's on the line for sure between the two.
Yeah, I was I interviewed Kane Replical from Richard Childress Racing, the NASCAR team and talked about the stuff he was doing with wind tunnels there as well. And yeah, it was like an insane amount of Excel they are doing over there in NASCAR as well.
Like, yeah, I mean, if you have the tool, and you don't really know programming that well, but like, if we put it here, we can like, ease it together. I could see how you kind of put yourself into that corner of like, well, it works over here. But exactly.
Oh my gosh, is it slow and hard, right?
Again, it was when you had people who'd only ever used Excel, who were starting the teams, or at least coming into the teams when technology was picking up, you know, this is what they picked, that's what they knew.
Yeah.
And you soon outpace that. I mean, you know, obviously, Excel gets quite flaky when you put this level of data in. But then also you have the problems, you've got one instance that you can open, and that's it. So you had the situation where someone in the office next door would open your Excel sheet, and then the wind tunnel would stop
adding data to the sheet because someone else had opened it.
Because Excel took a lock on that file, and that can't be written to or something like that, right? Yeah.
Oh, gosh.
Exactly. It works while it worked. And then we were very happy to overwrite it.
I mean, as much fun as it is to like make fun of Excel, and there's like all these examples of minor Excel errors leading to really catastrophic decisions, like large investments that were very bad and all sorts of stuff. But it's also I think it's also worth just admiring, like you said, okay, these people came from here, and they just knew Excel.
Yeah.
But they built this, this simulation thing, when they didn't really know programming or programming language, and they still did it like that's pretty awesome.
Yeah, no, I agree. And you know, that applies to the bash stuff as well. I don't think I've met many developers that could sit down and write 10,000 lines of bash.
You know, and I don't know I could do it. I might quit before I got to 10,000.
And it worked pretty well for five or 10 years. It's certainly impressive in its own right.
Yeah. So a lot of these things are both Yeah, like a lot of these are both like, triumphs, but also it's like time to move on, right?
Exactly.
Yeah.
So I think Matt,
I'm so sorry, I sort of derailed you from this MATLAB thing. So tell me about it.
No, no, that's good.
I'd say that the MATLAB side, unlike the other two, we wanted to replace bash and XL because of the obvious limitations. But the reason that we wanted to replace MATLAB was, I mean, purely the cost and the cost for what you gain from MATLAB.
You know, MATLAB can be very good when you're doing very complex things. It can simulate discrete or even bits of electronics if you want it to. So we have people that will make a model for how a tire deforms.
And then that becomes a component in MATLAB. And, you know, it's nice that you can then share that with other people in the company.
Right.
But a lot of the stuff they, you know, do is just analyzing the how many times a tire heats up and cools down during a lap and what window of temperature it sits in. And you just don't need to be paying several thousand dollars a year to do to work that out.
Well, and it also gets harder to run in situations like, say, with Docker or other stuff, right?
Like, yeah, if you want to put it on a server or scale it out, all of a sudden you're like, well, we got to get approval to run it on 10 machines instead of one.
It's not even necessarily a cost. It's just like, why is this friction here?
Yes.
If I can just as equally do it somewhere else.
Yeah, exactly. And you had times where race engineer might drop their laptop and get a new one set up at a race weekend.
But their MATLAB license was tied to the old laptop, so they couldn't get that immediately.
So that was a problem.
So the job was basically just to work with the vehicle science department to make a few Python scripts.
Effectively, they were just, you know, it weren't much more than just scripts to replace as much of MATLAB as we could.
And really, it was just me teaching them the basics of sort of NumPy, Matplotlib.
And then they just took it and ran with it.
Yeah, beautiful.
And you can do, there's so much of NumPy that replaces Matplotlib.
And as you say, not only is it something that they can do on any laptop, you can then start actually scheduling it as well.
So rather than having to manually run it every lap or whatever, they can just schedule it to do that.
Yeah. So you replace MATLAB with NumPy and Excel with Pandas and you're kind of good, right?
Exactly. You're at the races, quite literally.
You're off to the races. Beautiful.
Yeah. So that sounds like a really fun project you did for like three or four years to just go, okay, what if we started over?
What if we really built what we wanted instead of what we were able to do?
And yeah, how did people in your department and at the team react to seeing that sort of transform?
So it was a good mix.
One of the things I really enjoyed about working in F1 is you're sat next to your customers, which I know might sound off-putting, but honestly, it was great.
No, it's super cool.
If somebody came over and like, this is beautiful what you built, but if you could just do it slightly just like this, instead of, you know, well, next release, like, okay, give me five minutes.
Yeah.
Let me make that tweak.
And then they're like, yeah, this is fantastic.
Exactly.
Right. That's a cool experience.
I've had that too.
And just seeing someone's face light up when you've gone from a very static web page where you're, you know, having to load literally an x-axis by x-axis of plots to being able to literally just add a click of a button, change the variable on one axis, change what position in the car that plot is looking at, then say, save that, add another one to the page, compare the two, you know, overlay them, etc.
It's great to sit and see that, you know, everyone in Formula One is under a lot of pressure.
So anything, anything that you can do to help take that pressure off people, they're going to appreciate it very quickly.
Yeah.
And anything that helps them find performance because then they look good.
Sadly, I'm not that they're getting a pat on the back for someone designing a great new bit of aero that's adding time to the car.
But it is nice to know that the processes I've put in place has enabled them to do it.
Yeah, super cool.
Are you still a fan of F1?
Do you watch it these days?
Not as much as I just found out, but I have, I think it's ESPN in the US.
So I moved to the US recently.
So I'm still getting my bearings on how to find various TV shows and things I want to watch.
So I watched Imola and Portuguese Grand Prix, mainly because they're two very exciting tracks for me.
The Toroso factory is very close to Imola.
All right.
So I've walked the track quite a few times.
I've been to coffee outside the track many times.
Or I always wanted to do a track day there.
And sadly, the stars never aligned.
That would have been fun.
But it would have been.
I probably would have got a bit too excited and ended up crashing.
But it was a particularly nice track.
So one that I was very keen to get some time on.
There's still hope.
I still have friends that live near there.
So maybe I'll pay and do a proper track day.
You might make it back there and get there.
Yeah.
I've been back since leaving.
I've been back there a couple of times, actually, for sort of mini holidays and things.
And you can go and rent budget race cars there to do a few laps in, which I might do hopefully after the pandemic clears up.
Yeah.
That sounds fantastic.
I'd love to do that, too.
All right.
So one final question.
I kind of want to put all these pieces together and get your thoughts on it.
So this racing world, my sense is like, it's pretty high pressure.
It's high stress.
It demands a lot of your time.
And you talked about these events, right?
Like the software has to be ready to deliver on a date.
And it's not like, well, we'll push the release a week.
Right.
It's got to be there for that thing.
Right.
And now you're working for a tech company building almost like an operating system layer for deployment.
Yeah.
What's that comparison look like?
Like if people are in one and they want to think about the other, like what your two worlds look like in those times.
So certainly my work life balance has shifted towards life quite a lot, which is nice.
I mean, it was a great seven odd years that I spent.
I learned a lot.
And the pressure was a good thing to learn a lot.
It was the right amount to help there.
But it's the kind of the any way I can think to describe it was move fast, but don't break things, basically.
So we had to anything that went wrong, we had to fix quick.
Right.
We weren't towards the latter time at Toroso.
We tried to get some sort of like real sprint planning going forward rather than just kind of picking stuff that was being shouted at the loudest or shouted for the loudest.
So we tried to get some more calm and some stability.
But ultimately, if something's broken, unfortunately, the things that would break wouldn't usually be our tools.
It would be maybe the company that we'd paid to write the simulation software.
Something would change in that.
And we had to rewrite the function that read data from it.
So that stuff had to obviously happen very quickly when it does go wrong because you just can't waste a minute.
Or if there's, you know, a node goes down because there's a problem in the data center or something, we have to mitigate that really, really fast, as well as delivering all of these fancy new toys that we've promised.
And they can't break either.
So it is nice.
Oddly, we did barely any integration testing.
It was never really on our agenda.
It was more sort of get as many features out as possible.
And I have to admit, I do much prefer now being somewhere where testing is mandatory, you know.
A little more of a safety net.
Exactly.
It's a lot more reassuring to hit the release button when it's been through at least some agreed upon tests rather than just being like, well, I've tested this on my laptop.
You know, my work laptop.
Hopefully it will work on everyone else's.
Exactly.
It works on my machine.
We're good.
Exactly.
Chip it.
Nice.
Cool.
Yeah, if anyone's thinking about going into, you know, that industry, then it's going to be intense for sure.
If you can thrive off that environment, then you're going to love it.
I think a lot of people are in the kind of mindset that they can thrive on it for a while and then they just need to have a bit of a break for a while.
Some people have put up with it for 20, 30 years.
You know, I've worked with some people who have been in F1 for that kind of length of time and we're still loving it, which is great to see.
Yeah, good for them, right?
I'm a big believer that careers go in sort of seasons, right?
There's part of your life where you might be young and energetic and you don't have a large family time commitment and something like this would just be perfect.
But then that same person 10 years later might actually hate it, right?
They don't want to be away from the family.
They don't want to be away from a home or like there's just...
It depends where you are, not just who you are, I think.
Like where you are in your career, yeah.
Exactly.
And it's been nice working with different things.
So we never really exploited Kubernetes in either of the teams that I work for.
It was something that we were starting to look at, but most of our provisioning was bare metal provisioning.
So to have a software layer on top of that, we were talking earlier about the operations per cycle limits, like having a bunch of virtual networks that Kubernetes put together on top of that is just going to suck cycles away.
Right.
So we were thinking about doing that with the Django app, actually, to put that in a Kubernetes cluster across those two nodes.
But, you know, in the end, Docker Swarm was plenty for that.
There's no need to complicate that further.
Right.
There's always the opportunity to, but...
That's right.
There is.
Well, that's a super interesting look inside of your time in F1 and the Python.
It sounds like Python played a super significant role there.
Yeah, definitely.
I'm fairly confident that the majority of teams are pretty deep into Python now, purely because it works great.
It's the kind of blue code that you need to be driving these kind of commercial softwares that are used for each stage of simulation.
You can then, with the same bit of code, start making a bunch of images and plots.
You can have your web server running in it.
It's so kind of diverse in that sense and fairly easy to pick up.
I should mention that although I was the kind of primary software engineer at both teams, for the aerodynamics department at least, you know, I had a lot of input from people who trained as aerodynamicists but wanted to learn Python.
And, you know, for the most part, found it quite easy.
What is this magic that you're wielding over here?
Exactly.
For example, if you wanted a certain picture to be made that we weren't currently making, an aerodynamicist could just sit down, change a few lines of code, push it into a Git branch, and we could have that running in a couple of hours, which is really powerful.
To give someone the ability just to say, right, I want this to be added to this big chain of steps, and it just works.
Yeah.
Super cool.
All right.
Well, I think we're out of time, but it's definitely a neat look inside.
Now, before I let you hire you, though, I've got to ask you the two questions that go at the end, of course.
Sure.
If you're going to write some Python code, what editor do you use?
So now I use VS Code.
I'll admit that I used PyCharm through my whole F1 career.
Yeah.
All right.
And I've been pulled over to the VS Code side.
Interesting.
Yeah.
And I think it's down to those two these days.
Like, those are the most popular answers.
It used to be a lot more variety when I started the show, but now it seems to be settling into those two camps.
So, yeah.
And then a notable PyPI package, something that's cool that you've run across that maybe people should know about.
Yeah.
So I've been writing some tests recently, and I had a function that I didn't really that would run a part of this code.
And basically, it would take a while for the application running behind it to settle.
And I didn't really want to put a bunch of sleeps in there.
That just seemed bad.
And I didn't want to write my own back off loop.
So basically, I found that there's a package called back off.
And you could just decorate methods or functions that you want to be backed off and then provide a bunch of parameters, like how many times you want it to try.
How long you want it to wait before the next attempt.
It was really nice.
You just literally put the one decorator around your function and it's done.
Yeah, that's really cool.
And you can do things like back off on exception of these types of exceptions, then just slow down and try it again.
And so on.
Yeah, it's really nice.
Especially for writing tests.
Some kind of like too many requests.
You know, what is that?
Some 400 error, right?
Like there's someone that says too many requests.
That one, let's just slow it down a little.
Yeah, so if anyone's dealt with the AWS API and has got that, the rate limiter from there, this is a great library for that.
Okay, cool.
Yeah, it's a great one.
And I hadn't heard of that before.
Very neat.
All right, final call to action.
I'll give you two angles here.
One, if people want to get into some kind of racing career with software development skills, what should they do?
And then maybe getting started with your Kubernetes charms, charmed Kubernetes stuff.
Sure.
So if someone wants to get into, I mean, the Formula One software development side, there's really two approaches.
I think most of the aerodynamic and the sort of wind tunnel, well, both the CFD and the wind tunnel side will be Python these days.
A lot of C# is being used in Formula One now as well.
So if there's anyone who's got a taste for C#, anything that's done on Windows will be written in C# now.
So for example, the driver in the loop simulators, you know, the actual simulators the drivers sit in will be all written in C#.
So yeah, you don't even really have to be that big into F1.
I happen to be because I've been racing since a kid, since I was a kid.
But yeah, as long as you've got some sort of basis in Python and or C#, just apply.
I mean, just try.
I really wasn't that experienced.
I got a, you know, a lucky break and exploited it to as much as I could.
Beautiful.
And then Charmed Kubernetes, people are interested in that?
Yeah, sure.
So we at Canonical currently have two Kubernetes products that we are working on at the moment.
One is called MicroKates, which is a very opinionated distribution of Kubernetes.
It started off as a single node distribution.
So if you just had your dev laptop and you wanted to test some Kubernetes application that you were writing,
you could just literally in one command install MicroKates.
Now with there's a lot of demand coming from sort of IoT and Edge devices,
you can now run them in a proper Kubernetes cluster.
So with literally one command to install Kubernetes and then another one to add it to your cluster,
you've got it.
So if anyone's used kubeadm, it's similar, except for you've got everything in your MicroKates package.
You've got the container runtime and the API server and everything else.
Oh, yeah, that's neat.
I mean, normally I think of Kubernetes being a server side, big server type of infrastructure, right?
Exactly.
So one of the things that also put me off using Kubernetes in the Formula One team was basically testing on it was quite tricky then.
So with stuff like MicroKates, it's really easy.
You can just define the infrastructure that you want to test and you can just run it in MicroKates,
whether that be on your local dev machine or in CICD.
And now if you've got a bunch of Raspberry Pis running on some Edge platform, you can do the same.
It's just a single command to install it.
You have everything you need in that single package.
And yeah, you just add them to the cluster with a single command as well.
So a total of two commands to install it and enroll it.
And then if you want a less opinionated Kubernetes distribution, all of the kind of the actual code behind it is all written in Python.
It's called Charm Kubernetes.
It runs off a product called Juju, which is basically the actual program that deploys and then monitors your Kubernetes cluster
and then enforces that what you've asked for stays.
So, you know, you can choose between the different run times.
So if you want a Docker or a container D runtime, you can swap out your CNIs, so Flannel, Calico, etc.
All with single line commands.
And you can do it on a running cluster.
And because of this sort of Python infrastructure code that we have running in the background, it's handling all of that for you.
You're not having to either reapply it or gracefully bring down your cluster first.
It will all do this on a running cluster.
Wow.
That sounds neat.
Awesome.
So, yeah.
Two very different paths for people to check out depending on what they're interested in.
So let me just ask you real quick, since you mentioned it, what kind of racing did you do?
I did endurance karting.
So there was a series called EPEC, which is European Pro Kart Endurance Championship.
So we did 24-hour races across Europe.
No way.
24-hour kart races?
Oh, my goodness.
Yeah.
So there were three or four of us per team.
We do two or three hours each and just keep rotating like that.
People might think of karts as like things they go ride at little adventure parks.
But the racing karts are beasts.
Like those things are really fast and intense.
So, yeah, it's an interesting world.
They're cool.
Yeah.
They're not the kind of bachelor party things that I think you'd imagine.
They're capable of doing 100 miles an hour.
So you do have to have your, you know, it's not good to be sleepy.
Two inches off the ground.
Oh, if that.
Two inches off the ground with no seatbelt, right?
Yeah.
Even.
Two millimeters, I think.
Oh, my goodness.
Well, Joe, this is a super cool look at what you've been up to.
And thanks for sharing another cool Python story.
Thank you very much for having me.
Yeah, you bet.
Bye.
This has been another episode of Talk Python to Me.
Our guest in this episode was Joe Borg.
And it's been brought to you by us over at Talk Python Training and our friends at Linode.
Simplify your infrastructure and cut your cloud bills in half with Linode's Linux virtual machines.
Develop, deploy, and scale your modern applications faster and easier.
Visit talkpython.fm/Linode and click the create free account button to get started.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.