The Python Podcast.__init__

Share on social media:

Visit our site to listen to past episodes, support the show, and sign up for our mailing list.

Summary

Service integration platforms have traditionally been the realm of Java projects. Zato is a project that shows Python is a great choice for systems integration due to its flexibility and wealth of useful libraries. In this episode we had the opportunity to speak with Dariusz Suchojad, the creator of Zato about why he decided to make it and what makes it interesting. Listen to the episode and then take it for a spin.

Brief Introduction

• Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
• Subscribe on iTunes, Stitcher, TuneIn or RSS
• Follow us on Twitter or Google+
• Give us feedback! Leave a review on iTunes, Tweet to us, send us an email, leave us a message on Google+, or leave a comment on our show notes
• I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at
• I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of Podcast.__init__. Use the link hired.com/podcastinit to double your signing bonus.
• Linode is also sponsoring us this week. Check them out at linode.com/podcastinit and get a $10 credit to try out their fast and reliable Linux virtual servers for your next project.
• We are recording today on October 27th, 2015 and your hosts as usual are Tobias Macey and Chris Patti
• Today we are interviewing Dariusz Suchojad about Zato

Interview with Dariusz Suchojad

• Introductions
• How did you get introduced to Python?
• Can you explain what Zato is and what motivated you to create it?
• What makes Zato stand out from other service bus implementations?
• What are some signs that someone should consider incorporating Zato into their software architecture?
• Does zato perform well in restricted resource environments like ec2? What performance bottlenecks are common when using zato?
• It seems that most other ESB projects are written in Java. What advantages does Python have over Java for this kind of project and in what ways is it inferior?
• The architectural nature of ESBs are such that they form the central backbone of a software system. How have you been able to ensure an appropriate level of reliability and stability in Zato while still delivering new features and improvements?
• What are the scalability and high availability characteristics of Zato?
• Does zato run well using pypy?
• For anyone wanting to use Zato, what are the infrastructure requirements for deployment?
• What are some of the security ramifications you took into account in zato’s design?
• What are some of the most novel uses for Zato that you have seen or heard about?

Picks

• Tobias
  • SPY
  • Eric Royer’s One Man Band
  • pip-tools



• Chris
  • Rational Security
  • New Rustacean Podcast
  • Johan Goes to Mexico



• Dariusz
  • Sublime Text Editor

Keep In Touch

• zato.io
• Twiter
• Github

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. You can subscribe to our show on Itunes, Stitcher, TuneIn Radio, or add an RSS feed to your podcatcher of choice.   You can also follow us on Twitter or Google plus with links in the show notes.   And please give us feedback. You can leave us a review on iTunes, send us a tweet, send us an email, leave us a message on Google plus or leave a comment on our show notes. Leaving a review on iTunes will help other people find our show so that they can enjoy it as much as you.   I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.  

For details on how to support the show, you can visit our site at pythonpodcast.com.   I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of podcast.init.   Use the link hired.com/podcast   init to double your signing bonus.   Linode is also sponsoring this this week. Check them out at linode.com/podcast   in it and get a $10 credit to try out their fast and reliable Linux virtual servers for your next project.   We're recording today on October 27th   2015, and your host, as usual, are Tobias Macy and Chris Patti.   Today, we are interviewing Dariusz Suhoad   about Zato.  

Dariusz, could you please introduce yourself?  

[00:01:30] Unknown:

Hello, everyone. I'm Dariusz.   I'm assistant architect,   a programmer, and a primary author of XATO,   which is an integration platform and backend, an API server written in Python and designed from scratch with Python programmers in   mind. That's that's that's that's what I do.  

[00:01:50] Unknown:

That's great. So how did you get introduced to Python?  

[00:01:54] Unknown:

Some 15 or 16 years ago, I was reading a book on Java. The the book was called Thinking in Java   and at 1 point the author mentioned that 1 should definitely have a look at Python.   It got me curious because it was a book on Java,   and here the author is   mentioning another programming language, so I   paused the book,   downloaded Python, and actually, I never get back to   that to that book again.   I stayed I just stayed with Python,   though, eventually, I did spend several years using Java as my programming language,   for, so, 5 or 6 years, but Python has always been the only language I I you know, I could I could truly I was truly able to express myself   in. It's the only language that that, you know,   I just feel it lets me   fly. It's the only language   that doesn't force me to work around it.  

Instead, I can work with the language   to achieve a given result.   So, despite being a polyglot programmer,   I consider myself   a Python   Pythonista primarily.  

[00:03:14] Unknown:

And so does your time in Java, is that what inspired you to create Zato in the first place? What gave you the idea?  

[00:03:24] Unknown:

Well, yes. You can you can, you can say so. Just,   my background my what I've been doing for for some   15 years is is enterprise,   applications integration. So,   it's it's   it's the domain that,   that that typically   sees Java in use.   Java or C, C plus plus   some dot net,   and,   and,   and the score of proprietary,   4 gsLanguages.   And,   no, at 1 point at 1 at 1 point, I I simply had enough of it. I understood that Python   was the very high level language that   would be would be great for what I was doing   except that there was no platform for for doing it. Everything was either in Java or c or c plus plus   So   someone some someone simply hate to do it, and turned out it was me.  

And at 1 point, I simply quit my job, sat down to work, and created Zato after some 2 or 3 years.  

[00:04:39] Unknown:

And can you give a more in-depth explanation of what Zato is and what makes it stand out from other service bus implementations?  

[00:04:48] Unknown:

Well, that is an it's an integration platform. It's a it's a dedicated piece of software. It's a piece of software dedicated to integrating   other applications.   So   if you if you're if you're doing something like calling several REST endpoints,   combining the responses,   and   reaching out to an AMQP   AMQP   broker   and collecting some responses again that are transferred into XML or JSON, depending on what the output format is   required   in a given situation,   and XaT is a software   that simplifies the process.   And you can you can do all the transformations of the you can establish all the connections   straight from Python.  

It's a platform which offers a lot of adapters to   to actual technologies like MQP, 0MQ, WebSphereMQ,   REST,   so Cassandra   SQL, you know, there's a there's a lot of it.   So that in your code,   instead of thinking about how to connect to a to a given technology,   you are basically given a dictionary on input, and you need to   provide the framework with a dictionary on output so that someone calls you, someone calls your code, the code is exposed to an API, which can be can be a solved API, it can be a REST API,   it can be an AQPQ,   but no matter what the transport, no matter what the technology   it originally is,   you in your in your code, you see a dictionary,   a Python dictionary,   or it can be any other   data type, but it's it's simply easiest to to work with dictionaries in Python.  

So you get diction the dictionary, you extract some data from it, provide it on input to a call to an external service, like another another endpoint.   Okay. You take the response and   provide some interesting and useful output out of of it all. That's that's about what integration service are about.  

[00:07:04] Unknown:

And can you describe some of the ways that you have architected Zato to be able to have appropriate performance characteristics for being able to ingest   and send data out from,   multiple different endpoints and be able to do that in a scalable manner?  

[00:07:22] Unknown:

Right. So that is based on g event, which is based on leap event.   And to be precise, data uses   gunicom,   which is a very scalable server in Python that lets you leverage   multiple CPUs,   yet at the same time,   it's an it's a so called asynchronous server, so you can accept a large number of TCP connections   despite there being   only a handful of of CPUs.   That's,   that's how the core networking part works.   Each Sato each Sato environment   is 1 or more clusters,   so there's a built in load balancer   to distribute the traffic   across multiple servers   in case 1 server is not enough.  

And,   you can you can you can you can have as many services as you need, as as many services as are required to handle a given traffic and throughput.   Another point is that in Python,   you know, 22 most common commonly used data formats are XML and JSON.   And   in Python, we've got the excellent   lxml library   to deal with XML,   and   there are libraries   to quickly process JSON.   Both are,   both library libraries are written in c.   So,   essentially,   despite being   in Python,   the core loops, the core parts   run at c speed in zerto.   So   in case anyone was wondering if Python is is   fast enough   for that kind of software, yes, it is,   because because it it really runs at the speed of rows of rows c.  

So there are there are fast libraries for parsing for parsing the messages.   There are servers. Servers can use   can use as many CPUs,   as you give them.   Plus, there's a load balancer in front of all of the servers,   so you can scale,   you know, to 20 level that that's required.   And if a single class is not enough,   you can have as many classes, as you need. So that's how that's that's how the   scalability works. You can you can scale to you you you can scale to   to to to any needs.  

[00:09:56] Unknown:

Does Zato perform well in restricted resource environments like EC 2?   What performance bottlenecks are common when using Zato?  

[00:10:05] Unknown:

Well, honestly, I I I'm not aware   of any preference bottlenecks   when when using Zato, like, you know, like I just   described it. You you can   you can have as many servers, as you need. You you you as as long as you've got a Linux system,   as long as it's, as it's Ubuntu, Debian, or   CentOS, or Red Hat,   you you you can scale it to to any needs. So   it performs very well regardless of what the what the what the environment   really is as long as it's   a as it's a Linux system.   So   it definitely runs in   on Amazon,   or it can run-in your own data center. It doesn't really matter. It's it doesn't need much resources.   It's fast enough for   for for many needs.  



[00:10:58] Unknown:

That's great. I mean, just to give you a sense of why I asked the question, both Tobias and I worked at a company where they used,   Red Hat's   oh, god. Java,   integration platform.   Camel. Camel? No. That's the that's the protocol. But in any case,   it it used the Java based ESP,   and it and it worked great, but it, unfortunately,   had this tendency and this habit of   consuming all available memory and CPU   on the ECT nodes that we were running on, effectively crushing them to death. And so   that's kinda why I was asking   what kind of resource   constraints   Zato ran well under.  



[00:11:42] Unknown:

Oh, yeah. That's,   Yeah. That's I I understand how how it's possible, but, yeah, in Zato, you you a single server running,   using a single CPU,   in idle state will use about, I don't know, up to 100,   100 megabytes of RAM.   So that's that's how that's,   that's how much it needs   right after it started.   And   I am aware of a few environments,   that's,   that's been running   for about 2 years now on something like   a gigabyte of RAM,   and   and it simply works. They they simply they simply work. They've never been restarted, and   it's all fine. So it's   it's very good as far as as as the resources go.  



[00:12:34] Unknown:

And so you mentioned that those instances have never been restarted, and I know that reading through the documentation,   Zato supports hot code reloading. So could you delve into that a little bit about how the reloading works?  

[00:12:46] Unknown:

Right. So   I've been always   sorry. I've been I've been always impressed,   by how Airline works.   I've I've heard this I've never used it really, but I've heard that it's possible to it's possible to   replace   the code on servers on Airline servers while they are running.   I thought, why shouldn't we have it in Python?   If we don't have it in Python, the language, why shouldn't we have it in Zato?   And so the way it works is that a service a service because everything in Zato revolves around services. A service is a piece of functionality,   which   essentially   serves some input, produces output. It's like it's like a function. It's like a it's just like a regular function.  

It's just it's just that it's distributed,   across multiple servers   and can be made available   across multiple APIs.   So the halt result feature   is, essentially,   the ability to   to delete   and replace old functions with new ones, old services with new ones.   So   you   during development, you edit a file, a Python module. You hit save.   The file is   stored   in a so called pickup directory,   and,   and the background process understands that there's a new file in this directory,   The file is picked up,   transported to all of the servers in the cluster, and immediately available available   everywhere.  

So you don't need you don't you don't you don't need to restart servers to to take advantage of the new code.   Same goes for for configuration.   You don't need to restart anything after changing anything. You if you've got a new credentials   for for a given input channel   and you update the password, the password is automatically made available   throughout all of the servers.   Same same goes for for any API and for you as delete,   edit,   or change in in in any way.   So that's   I I I don't particularly like like restarts. You You know, I've seen it far too many instances that service   won't boot up again after a restart, not because something changed   or our servers go, but, you know,   something can always go go go wrong as far as operating system goes.  

Why we start everything if you can only replace the parts that we need to replace within the the whole server? That's 1 school of thought because   there's another school of thought which which says that   you should always restart   servers because   because that that way, we we can we we can make sure to have both operating system   and the server   always   have always have access to   the latest updates   as as they become available.   That's what   people do   with Docker files, for instance. So that's also possible. We also have Docker files for   for each of the is that a component,   like servers, or balancer, or with admin.  

But it's extremely   extremely convenient to be to be able to simply hit save   and have the code available,   on all of the servers.   Or   simply   click in the in the GUI,   click update password,   and not have restart anything.   That's it it it's a tremendous productivity boost.   So that's that's that's something I really like.  

[00:16:42] Unknown:

Yeah. Being able to do automatic code reloading, it sounds like a very useful feature. And I'm wondering if you have made that available as a standalone module for people to be able to use in other systems.  

[00:16:55] Unknown:

Well, it's,   no. It's it's part of the of the framework, so the answer is no.   And it won't handle   any arbitrary   changes. The mechanism is aware only of the Zato services. So it's, you know, because there there are always complications   like   because I thought of it, but it's it's not it's not that straightforward. If you if you've got, for instance, live TCP connections to a remote server in a module, you know, on the global level. What do you do? How how do you hot reload it?   So you   if if if you give users the ability to hot reload everything,   you will, at 1 point, need to handle literally   everything.  

So and then how how how do how do you deal with such cases, like,   live connections to to servers?   Well, you you you can't. You you cannot do it without the cooperation from from users.   So it's,   right now, it's it's limited to to Zappos servers, which is what the Zappos platform is about. So so it's not any real limitation.  

[00:18:02] Unknown:

And it seems that most other integration platforms are written in Java, and I'm wondering what advantages Python has over Java for this kind of a project, and in what ways might it be inferior?  

[00:18:15] Unknown:

Well, you know, the   the the number 1 reason is that Python is,   is on a higher level than Java. So   in this kind of projects,   the productivity   is is what is most important. The ability to quickly, swiftly react to ever changing requirements   is of utmost importance.   So   the dynamic,   nature of Python is   what sets it aside from Java, and that's the advantage that has over   known Python solutions.   And as far as   these advantages go, you know, several years ago, I I would say I would say it was a bit problematic to use Python in in a few places because   proprietary   vendors,   simply   accustomed to to use either   Java or dotnet, c, or c plus plus   You you've had some COBOL,   and that that that that's that's that's pretty much it. But nowadays, you know, it's it's disgraceful and shame and shameful not to have at least a a solved API   or not to mention a REST or a RESTful API.  

So   I I I cannot really think about any   any disadvantages   to   to to using Python in for such a platform.   Even if there isn't a a client giving service side technology,   these days,   the technologies   themselves will will have   a soft or,   REST API.   So you can connect to anything,   which wasn't which wasn't exactly the case some 5 or 6 years   ago,   but now it's it's way more convenient to   to connect to any proprietary   technologies from Python.  

[00:20:13] Unknown:

And so the architectural nature of integration platforms are such that they form the central backbone of a software system.   And I'm wondering how you've been able to ensure an appropriate level of reliability and stability in the Zato project while still being able to deliver new features and improvements.  

[00:20:31] Unknown:

Well,   right now, we had a major upgrade from the   initial release   to the to the newest 1. There are a lot internal   internal   changes. So   right now, if you had   that 1 environment and you wanted   to upgrade it to that 2,   you needed a full shutdown.   That's,   that's how it looked like. However, right now, any new features added to the to the platform,   don't assume that there will be a full shutdown,   at any point. So   everything   everything is,   able to grace gracefully handle   situations   where, for instance, the configuration database   changed   between any calls to to your service.  

So, for instance, let's say you've got 2 servers   in an environment and you want to upgrade it to to to a newer version. You can indicate in in on the local answer that 1 of the services   is is down for maintenance,   upgrade the server,   start it back,   and the server, despite being in a newer version, recently continue to to handle the, the traffic.   And then you can take the other the server down, upgrade the binary,   restart it. It will simply work.   That's how it can work.   And, of course, you you you can always use Docker files,   but you can simply replace the the old files with with new ones. So   you won't you won't even have to   restart in service. We will start the whole operating system, but the whole container. So that's   you can   that that that's how it looks at. So you can replace the binaries   on each server separately.  

That's how it will look like in your releases.  

[00:22:20] Unknown:

So how how do you do that?   I I realize it's a it's a perhaps overly simplistic question, but, you know, thinking   of my own Python programming, I think about   the parts of my programs and the classes that interrelate.   I I've got to imagine that there's some extra architectural   secret sauce that you used to enable that capability. Can you give us some details of of what that was?  

[00:22:45] Unknown:

Well, no. Everything everything in Zato internally   is based around services. It's a it's a service oriented   architecture, and there's   there are not that that that many   dependencies   in the, you know,   in the in the in the Python sense that,   you know, we've got modules. We've got modules. We've got,   internal components, but   everything is really a service. So a service can   can can have the you know, it's coded in a way that that understands   that some data may be missing because it was edited in a new version.   It's it makes the code less,   well, less convenient to develop,   but it's all for the purpose of people's having,   you know, less downturns,   if at all.  

Plus on top of that, we use Redis extensively.   So it says schema less it's a schema less database.   So   even if if the schema changes,   then there is 3 no schema.   So 2 versions of the same service can happily   live with the same redis database.   And if something is missing, then it's it's it's simply won't be   possible to use it,   you know, if some data in the database is missing.  

[00:24:07] Unknown:

So so just so I can understand you correctly, you were saying you use the Redis database. Right? Okay. Thank you.  

[00:24:14] Unknown:

So I was going to ask about how the scalability story works   If there's any sort of auto discovery   that Zato does in terms of being able to scale out clusters or if if it needs to be explicitly set in any configuration file? And,   just wondering how dynamic you can make your Zato clusters.  

[00:24:35] Unknown:

Well, you know, no. There's no auto discovery mechanism.   I contemplate I contemplate that, if it should be added. Yeah. Because it's convenient to have it attached.   On the on the other hand,   it could be,   a security issue that, you know,   some that that someone can simply start a new server and make you join the already existing cluster.   So   I'm sure it can be worked around, but at that point, you you   you simply need some sort of manual configuration.   So if it's needed,   you you can as well just,   not use the auto discovery   mechanism.  

So right now, if you if you if you let's say you got 2 servers and you'd like to add another 1,   you start it.   You point it to the you point it to the cluster,   but you need to do it from command line   manually.   And then you log into the web admin and point the load balancer to it   because there's   that's,   there's never any   traffic from servers to the load balancer.   So the load balancer needs to be told that there's a new server it can direct traffic to.   So that's how you can scale it up,   but, no, there's no auto discovery.  

[00:25:59] Unknown:

So does that run well under PyPI?  

[00:26:04] Unknown:

Well, I've never I've never really tried it. It would be a nice exercise because it sounds like a like a great application for pipe. There there are parts of the,   of the platform that, you know, they've been stable for for several years now.   What they do   is is, you know,   go through go through a list of headers or anything like that, which no. The the perfect use cases for just in time compiler. No. I've never tried it. I never tried it,   and I guess,   I guess I should at 1 point.   But, no, I just I just I just don't know right now.   Could be it it it could be a fun exercise.  

So I I hope it would it would it would run great.   And, you know,   I don't think that there are any set Cypress on specific features we use.   So as long as we can get PyPI running,   I I don't I don't see why why it shouldn't work and   why it shouldn't,   speed everything up.  

[00:27:09] Unknown:

And so for anybody wanting to use Zato, what are the infrastructure requirements for deployment? So,   you mentioned Redis. I'm just curious in terms of how the   overall deployment story works. Can you run it on a single instance, or do you need multiple instances for it to be able to operate   properly?  

[00:27:29] Unknown:

Right. So,   the only requirement is the Redis instance,   and,   plus, you need a Linux server. You need Ubuntu, Debian, or CentOS, or Red Dot.   And   that's it. The   that's it. We are we are thinking about,   replacing Red Dot so that that itself   would would be enough.   I think a Linux server is is enough. We've got,   we've we've got the command plan interface,   and 1 of them is,   1 of the commands is quick start. It's called quick start and   invoke it like   quick start creates   path to a directory,   and it sets up a working environment   consisting of 2 servers,   global answer,   and,   and the web admin.  

That's,   that's,   that's that's how we can get started in, like, no, 5 minutes.   You just you just you just need a a Linux class for cloud passes command.   There are environments   that are simply quick start environments renamed to development   or,   user acceptance test or production,   and they work just fine. There's, you know, there's no need to   to distribute the service across multiple multiple instances like my multiple operating systems.   If a single server is enough, then or   a single   operating system is enough, then then it's enough.   You can always add   service on additional instances and make them join the   the initial cluster.  

So   that's that's how it works. You you create everything from command line,   and then   in the web admin, you point the new you point the low balance at 2 new servers.   And then   everything simply works. Everything simply works. When a when a server starts up, it reads   reads up all of the configuration pieces.   If you if you, for instance,   take a server down   and deploy new code when it's down   and   bring it up after a week,   then the new code would will also be   read in,   so that the state across the service in the cluster is always in sync. Everything is always in sync.   You only need   to add service from from command line, and you can scale to any level.  



[00:30:04] Unknown:

That's great. So what are the some of the security ramifications you took into account in Zato's design?  

[00:30:10] Unknown:

Well, so so as as you can say, it's,   Zato is   a is a set of of servers   exposing t c TCP connections and TCP ports and establishing TCP   connections. So   the really critical   commands   are down from the command line. So   you cannot just be given web admin access,   and add or delete   service in a cluster. You need   access to the   system, so only then you can you can create   extend,   a cluster.   Plus, every connection, every TCP connection can be behind TLS,   so so it's encrypted.   Traffic to the low balance,   including client client certificates,   the traffic from the load balancer to servers, from servers to external systems.  

Everything everything can be encrypted.   Plus, we've got the policy of   there being no default passwords,   including no empty ones.   So we go to great lengths,   to ensure that   any any sort of password is either   generated   automatically and set to a UUID,   or   if there is,   or users are given instructions   how to generate it.   So now, for instance, a colleague of mine   is,   prep preparing images,   for Amazon,   Beanstalk.   And   and 1 1 1 of the things,   he'll be doing is   is to ensure that on the first boot,   password to the web admin is automatically set to a UUID   so that we don't have any default,   passwords   on Amazon images.  

So   you need SSH actual SSH   access to to the command line to to to prepare to   invoke the the the crucial   command.   Plus,   on the transport level, everything can be encrypted,   plus, the that there are no default password.   On top of it, we've we've got several security mechanisms   to   to security   APIs themselves. We've got API keys,   NTLM.   It's used when invoking   SOAP services on Windows.   We got,   basic auths. We also got, for instance, role based access control.   So that   on top of granting,   credentials to applications   connecting to your to your platform, you can group the applications into roles.   For instance, let's say you you provide an API   for,   for a banking system for a central banking system,   you can you can grant some applications, the role of account reader, but not   account   of data, for for instance. So that that so so that a   given application will be able to   check your account balance, but won't won't won't be won't won't be able to update it in any way.  

And the roles the applications are in   can be inherited. You can have a tree of roles.   And then   instead instead of thinking,   does that application   have access to to the to that banking system like this banking system. You said thing   what roles should I use? What roles should,   they grant to to a given application? So it's it's like a it's   actually mapped to HTTP verbs. So you can   create this post, read this get.  

[00:34:09] Unknown:

So what are some of the most novel uses for Zato that you have seen or heard about?  

[00:34:15] Unknown:

The project,   I I am on right now because,   it's really   it's really it's it's   really built around the service oriented   architecture. We we we are it's it's a project in health care.   We'll be the   health care integration platform.   We're integrating with some 6 or 7 systems,   and everything   is a service so that   instead of   implementing,   given a workflow,   instead of implementing workflow that   that is needed to put on front end or in front ends,   we add services that that that can that can be used by by by the front end to drive the user through a series of screens and forms.  

[00:35:04] Unknown:

So   last thing we usually ask is, are there any questions that we didn't ask that you think we should have? Or anything that you wanted to mention that we didn't bring up yet? No. No. I I think it's, it's fine. No. It's it's cool. Okay.   So with that, we'll go into the picks.   And so my first pick today is a movie I just watched last night called Spy,   and it's a slightly different take on your usual CIA operative movie. So it's just a very well done action comedy that I thoroughly enjoyed.   So definitely worth taking a look at.   And my next pick is Eric Royer's 1 Man Band.  

And this is a gentleman who has created a setup that will let him play   a banjo,   a   a   sorry,   a, an acoustic guitar,   and   a Dobro all at the same time.   And he's very talented at it so definitely worth taking a look.   And my last pick is going to be a Python library called pip tools,   which lets you   write your pip requirements   as a requirements dot in format   without   having to list out all the different versions   and all the different dependencies at the same time. And it will then take that of just the high level requirements that you have,   retrieve all of the dependencies   and their versions, and then output that to a requirements. Txt file so that you can pin all of the versions of all of your dependencies   at deploy time so that you don't have any surprises when you're going to deploy but you can also still manage   your requirements in a much more sane fashion. So definitely been enjoying using that recently.  

And with that, I will pass it on to you, Chris.  

[00:36:54] Unknown:

Very cool. Thanks, Tobias.   So my first pick is a podcast.   It's kind of unusual for me and that it has nothing to do with technology or art. It's called Rational Security.   And it's by,   3 people who are researchers at the Brookings Institution,   which is a   a centrist,   think tank. The the the podcast is about,   American security,   which sounds kinda nebulous. But basically, it is a podcast   about   the American interest,   from a security perspective in world affairs.   And it's really if you're someone like me who tries to keep abreast of the news,   it's really very interesting. It takes a number of stances into account.  

They're incredibly smart people.   And I just find myself learning a lot with every episode that I listen to. Great stuff.   My next pick is another podcast. It is called the New Rustation podcast.   There's another guy named Chris who runs this,   and he is doing an exceptional job. There are a lot of sort of, you know, learn programming language x podcasts cropping up now,   and I don't think   many others of them that I have heard are doing as good a job as Chris is in terms of, the way he he has thought out, his episode content. His presentation style is very clear and crisp. I really feel like I get a lot out of each episode.   And given that I'm I myself am learning the Rust programming language now, it's it's very timely. So   do definitely check him out if you are learning Rust. And if you do any kind of low level programming at all ever, or even find yourself thinking that it would be neat to have your Python programs,   you know,   run more quickly in certain spots,   then rather than reaching for c or c plus plus you should probably consider Rust, and, so his podcast could be of assistance.  

My final pick is a drink,   which I learned about at a really phenomenal,   bar that we have in the Boston area. To call it a bar is kind of damning it with faint praise. It, it's called Drink. It was voted,   in the top 50 bars in America, 2 years running now. Actually, maybe even 3. But in any case,   I tried a drink there called Johan Goes to Mexico.   It's a really interesting cocktail   that's made with mezcal   and a whole bunch of bitters.   And mezcal, and if you've never had it, is this incredibly smoky,   intense   alcohol variant that is somewhat akin to tequila,   but so smokier and more savory if that that that possibly can make any sense.  

But this drink, you get the smoky hint of the mezcal,   but it's balanced nightly nicely by the the sweetness of the bitters. It's really delicious. And and I included a link to the recipe, so   you too at home can give it a try.   Darius, if you have any picks for us,   now would be the time. If you don't, that's perfectly cool as well.  

[00:39:59] Unknown:

What about the only pick,   I could offer is that   no.   I definitely   recommend giving the sublime   text,   editor a try if you are into   a new,   Python IDE.   So I I I'm a long time weak IDE user. I always on the lookout for for new tools to   increase my productivity.   And despite not despite not being an actual   IDE,   I am very impressed with how fast and how convenient   for a programmer   sublime text is.   I was aware of it, like, a year or 2   or 2 years ago,   but now I I believe it's gotten even faster, and it's definitely   worth checking out if you're not using it already.   So or even if you already have an ID,   it's always nice to have another detail   on the site, and Sublime Text could beat.  

That's my pick.  

[00:41:04] Unknown:

Alright. Well, thank you very much for taking the time out of your day to join us and tell us all more about Zato. And for anybody who wants to keep in touch and follow what you're up to and the progress of the Zato project, what would be the best way for them to do that?  

[00:41:18] Unknown:

Well, please visit zato.io,   and we're on Twitter,   zato source on GitHub, zato source, and there's a mailing list. But everything starts at zato.   Io.  

[00:41:32] Unknown:

Excellent.   Well, we appreciate your time, and I'm sure that our guests will enjoy learning more about this project. And I'm sure a number of people will be happy to know that it exists so that they can   either extend their current architecture or perhaps replace some Java that happens to be running in their stack somewhere.   So I appreciate your time, and I hope you enjoy the rest of your day. Okay, man. Thanks. Take care, everyone.  

[00:41:57] Unknown:

Thank you. Bye bye.