The Python Podcast.__init__

Share on social media:

Visit our site to listen to past episodes, join the mailing list and support the show.

Summary

uWSGI is one of the most versatile application servers available. It was originally written for running Python applications and has since gained functionality to support Perl, Ruby, PHP, and more in addition to the incredible feature set. In this episode Tobias got to interview three of the core developers of this project and find out more about how the different pieces of it fit together and what its future holds.

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 or leave us a message on Google+
• 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. Sign up at hired.com/podcastinit to double your signing bonus.
• We are recording today on September 22nd, 2015 and your hosts as usual are Tobias Macey and Chris Patti
• Today we are interviewing the core developers of uWSGI (Adriano Di Luzio, Riccardo Magliocchetti, and Roberto De Ioris)

Interview with uWSGI core developers

• Introductions
• How did you get introduced to Python?
• For anyone who hasn’t come across the project before, can you explain what uWSGI is and what makes it unique?
• How did you architect uWSGI in order to allow for supporting so many different languages?
• The feature set of uWSGI is truly incredible. Does this make the code complicated to understand and modify?
• Can you describe some of your favorite features in uWSGI?
• What have you found to be the most overlooked or underutilized features of uWSGI?
• Can you briefly describe how Emperor mode works and how that can be used to handle routing between microservices?
• Could you discuss some of the particular features UWSGI provides around load balancing?
  • Is connection draining supported?
  • Can nodes be dynamically added and removed from the pool or does the config need to be rewritten and UWSGI restarted?



• The configuration syntax looks like it provides a very rich set of capabilities. Is it based on a general purpose programming language or is it a DSL?


• What might be some common use cases for using UWSGI in tandem with another web server like NGINX?


• I have read that WSGI does not get along with http/2. Are there any plans to look towards supporting that protocol in some way?


• What new capabilities can we look forward to in the future of uWSGI?

Picks

• Tobias
  • Manjaro Linux
  • Kontact
  • Blackhat



• Riccardo
  • Building Microservices book
  • Django-Denis



• Adriano
  • Paxos Algorithm



• Roberto
  • The Brink

Keep In Touch

• Mailing List
• #uWSGI on IRC
• GitHub
• latest docs
• Roberto
  • Twitter
  • GitHub



• Adriano
  • GitHub
  • Twitter



• Riccardo
  • GitHub
  • Twitter

[00:00:14] Unknown:

Hello, and welcome to podcast.init,   the podcast about Python and the people who make it great. You can subscribe to our show on iTunes, Stitcher, or TuneIn Radio, or you can add our 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.   Leave a review on iTunes, send us a tweet, send us an email, or leave a message on Google plus.   And 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.  

We are recording today on September 22, 2015,   and Chris Patti is actually not able to join us today. So your host today is Tobias Massey.   Today, we're interviewing the core developers of uWSGI,   Adriano, Ricardo, and Roberto.   Could you please introduce yourselves?  

[00:01:05] Unknown:

Hi. I am, Adriano.   I am a master degree student,   and I am the developer of many USB plugins.  

[00:01:14] Unknown:

So hello. I'm Ricardo.   I'm   a consultant,   specialized   in web development   and free software.  

[00:01:25] Unknown:

Hi. I'm Roberto. I'm the lead developer of the USB project.   I mainly work in the hosting industry,   and I'm a game developer.  

[00:01:35] Unknown:

And could you share with us how you each got introduced to Python?  

[00:01:41] Unknown:

I was introduced to it when I was looking for   a development language that was suitable for someone who had never programmed before. I was still in high school, and so, I don't know, I find it on the Internet, and I started learning it by myself.  

[00:01:59] Unknown:

I started   playing with Python,   like, 10 years ago.   I was looking for a script language.   At the time, it was,   something like,   sisademy,   and,   was looking for something   better than bash   scripting.  

[00:02:22] Unknown:

I started looking   at Python in 2003   because, I was working in a Perl based company   where making jokes about Python,   was the main   thing   to do every day. So I started looking at it, but I started using it, professionally   about,   2,007.  

[00:02:48] Unknown:

And for anyone who hasn't come across the project before, can you explain what uWSGI is and what makes it unique?  

[00:02:56] Unknown:

Okay.   For,   for a lot of people,   uWSGI can be seen as   an application server, but, internally, we prefer to call it as,   as a hosting infrastructure because   it is something that try to cover all the   poor people,   needs when they deploy   web applications,   especially for a system where you don't have   enough freedom to install external packages and and so on.  

[00:03:27] Unknown:

And how did you architect uWSGI in order to allow for supporting so many different languages?  

[00:03:34] Unknown:

Its main core is really, really tiny. I think being, being tiny   is the only way to accomplish that result. So,   we made   up extremely modular infrastructure.   So adding a new language,   is not so difficult,   as the current gives you only   a basis   to simplify the job of   interfacing   with   the USB server from   the CAPI   of the languages.   Basically, all of   the function   to do low level   interactions,   I mean,   especially non blocking,   programming   or interfacing with the configuration system are extremely simplified when you start embedding a language in uWSGI.  

[00:04:30] Unknown:

And how does uWSGI compare to something like,   Passenger, which is something that started off in the Ruby world?  

[00:04:38] Unknown:

I think it share   a lot of,   how could I say   we can say we have the same target,   passenger born has something to   allow easy deployment of, rails app and help   the developer, the programmer   to maintain,   the tap healthy in the web server. You always get start with the same,   target   but eventually during the time, it will, a lot with respect to passenger.  

[00:05:12] Unknown:

Yeah. It definitely seems to have a   much larger feature set than what passenger currently supports, though they have been adding a lot of other capabilities.   And speaking of the feature set of uWSGI, it's pretty incredible how many different capabilities it supports. And does that make the code complicated to understand and modify? Or does the plugin architecture that you mentioned make it easy to keep all those different capabilities segregated?  

[00:05:37] Unknown:

Absolutely. The modeler,   development   simplified a lot, the plug in development.   I think Adriano will answer.  

[00:05:46] Unknown:

Yeah. Yeah. I was thinking to that too because I approached the the code base when I first start working with Roberto, and I had no previous knowledge of uwhiskey.   But after just about a few months, I was able to write a pretty complicated plug in. So   you you all you have to do is to look at the source code, look at their examples. There are a lot of plugins already existing, and you can just make an idea of how things work on the inside.  

[00:06:17] Unknown:

I think the only really   hard part, if you want to develop, uWSGI plugin is interfacing with the non blocking system. As with a single code base, we need to support, multi threading and multi processing,   coroutines,   green threads. So that's probably the only   hard part to to grasp.  

[00:06:38] Unknown:

So every 1 of the plug ins needs to support asynchronous IO in order to keep from locking up the rest of the system?  

[00:06:45] Unknown:

The objective of the USKPI   is to abstract   the plugin developer from that kind of things. You have a bunch of functions to read, to   write, to open connections. If you use them, you are safe that, your plug in will be async safe.  

[00:07:01] Unknown:

Can you describe some of your favorite features in uWSGI?  

[00:07:04] Unknown:

Ricardo, start.  

[00:07:06] Unknown:

Okay. So my preferred feature is, I think, the spooler   because,   like, it was saying, Roberto, before,   it's 1   of these cool features   that,   when you don't have, like, a lot of resources   to manage external services, like in this case, a queue,   It's really   helpful   to have them integrated.   So,   you know, you can   start easily and add features, and you don't need   to worry   about   a lot of working systems.  

[00:07:46] Unknown:

Yeah. When I first came across the Spooler, I was pretty amazed at the fact that it would allow you to   avoid having to set up a Celery infrastructure, at least when you're getting started in order to be able to do,   background tasks?  

[00:08:00] Unknown:

Yeah.  

[00:08:02] Unknown:

My favorite 1 is the emperor, mainly for,   for its name.   For its amazing   personally, I need to deploy 100 of different application   on dozens of servers so something like that simplified my life, a lot.   It was 1 of the oldest feature introducing the project   effectively because   it was 1 of the much needed   for my own   needs.   So it's basically the 1 I like most.  

[00:08:33] Unknown:

And can I sidetrack the discussion for a second? It seems that the Emperor capability would be really useful in an environment that's taking advantage of microservices   because of being able to   mount multiple applications under a single overarching   container. Is that am I correct in that assumption, or am I way off base?  

[00:08:54] Unknown:

Yeah. Yeah. You only need to   differentiate between   mounting multiple application in the same process   that albeit so part of this is a really bad practice. Mhmm. I discourage everyone to do this.   But you can obviously   have different bustles. Bustles are the single instances managed by a single emperor, each 1 mapped to a microservice.   Maybe all of them are running in the same container or something like that.  

[00:09:27] Unknown:

And so the Emperor allows you to specify the routing between the different applications as well?  

[00:09:36] Unknown:

No. Because this would violate the unit's paradigm.   So you have another component for doing routing between instances. That's the fast  

[00:09:45] Unknown:

router  

[00:09:46] Unknown:

that you can obviously   start via   an emperor.   And the fast router basically basically is a non blocking server, a non blocking proxy that you can place behind,   NGINX, for example,   and, we start rooting your request by rules so you you can define to the to the notes. There is a variant of the fast router that's the HTTP router   that do the same thing but you can place it as the front most proxy.   It supports HTTPS   speed and so on.  

[00:10:21] Unknown:

Yeah. Having that capability baked into 1 toolset is pretty amazing, particularly given that uWSGI supports so many different languages, allowing you to have microservices written in each of those different languages all being mounted together   within the same overarching architecture so that the end user doesn't see any difference between the different services and they can just interact with the overall,   platform, I suppose.   I believe there was 1 more of you to list your favorite feature.  

[00:10:50] Unknown:

Oh, yeah. I think it was me. Okay.   Actually,   I like Spooler too, but Ricardo stole it from me, so I'm gonna change it.   And the 1 I 1 other feature I really like is   the subscription server. Basically, when you launch a service,   in my experience,   HTTP services,   You can just,   have multiple,   servers that   are Rick, Roberto will help me if something is wrong. But, basically, you can have multiple servers that are are working together, and those servers can be added dynamically to the operation.   So if you need more, they can just announce themselves to the web subscription server, and they're gonna cooperate.   So it's it's, it really seems it's really use useful to me.  



[00:11:44] Unknown:

Yeah. Mail, you you have the opposite the opposite of the standard setup where you add the nodes to the proxy. We go to the grid, restart it, and   it start, forwarding request.   With   subscription system, it's the it's the opposite.   The node subscribe to the proxy and the proxy automatically forward the request to them.  

[00:12:07] Unknown:

So what have you found to be the most overlooked or underutilized features of uWSGI?  

[00:12:13] Unknown:

I think,   internal routing   is not   so used.   There are very few examples,   in Stack Overflow and so on.   I think   as a lot of the new features are buzzed on it,   for those who don't know it, internal routing is   a kind of model right   but on steroids as it's,   is a an almost, 2 incomplete   language   embedded   in your configuration   allowing you to define rules based on the single request.   It even has go to.   You   can jump   in your request chain.   Another feature   is the offloading   but tends to a bunch of plugins   that are recently released,   this is gonna change. Basically basically, uploading allows you   to avoid,   making 1 of your workers busy in a simple task,   tasks like serving static files or doing WebSocket,   transaction,   and so on. Offloading   works by spawning, an external thread   with,   async capabilities   so a single thread, can manage a thousand of connections.  

For example,   the   the most,   common scenario is, spawning, 1 of those offload threads to service static files. So when the request for static files,   come to you, it delegates   you to   these offload threads. A single offload thread can truly manage 1,000 algorithms.  

[00:13:57] Unknown:

Yeah. I've recently been   taking advantage of that capability because   where I work right now, we host our application   in Heroku. And so being able to   use uWSGI to host those static files directly has been very useful and simplified the overall stack so that it didn't have to, for instance,   start using S3 for the static assets.   And also the   WebSocket capability, being able to offload that and host that within the same application container,   definitely seems really powerful. Particularly   for things like,   for instance, running   the flower application for Celery for being able to monitor your background queues.  

So could you guys dive a little deeper into the load balancing capabilities of uWSGI?  

[00:14:46] Unknown:

Okay. This is an area   where   we are getting a lot of improvements, thanks to IntelliSurfing.   That's a Perl based company that is   sponsoring a lot of new features in the 2.1 branch.   Load balancing,   I think, currently,   especially in the fast router,   service   is a lot powerful as,   differently from a lot of, proxy servers can be truly dynamic.   So you can remove nodes, add nodes   using the subscription   system, we've seen, before,   without the need to reconfigure the proxy.   The subscription system is based on a series of the UDP packets constantly sent by the nodes.   So when the proxies stop receiving those packets,   can know that the nodes is down   even before   routing a request to it.  

Currently, we are working on connection draining.   It is already available in the IntelliSurvey branch.   Basically, it allows to suspend,   request in   the Fast Tutor process   until some   backend node is available.   This has been developed   mainly for   allowing   the fast router   to contact the Emperor on Demand to spawn instances   only when the first request reach them. This is a pretty new feeder.  

[00:16:16] Unknown:

And so in terms of performance, how does the load balancing in uWSGI, particularly given its ability to   add and remove nodes dynamically, how does that compare to the load balancing for something like HAProxy or NGINX?  

[00:16:30] Unknown:

Well, both requires,   reconfiguration   of the proxy.   So   I think from   this point of view,   there is much space   for uWSGI to be a better choice. Regarding performance,   the fast router part is on pair with uWSGI. I'll bet they speak different, with NGINX. I'll bet they speak a different protocol.   HC proxy is a little bit more because   it uses some, low level techniques, especially on Linux systems that we don't use in, u w s g. I don't know if we will ever use, use it.   I mean, the use of the splice, Cisco   HAProxy.  

[00:17:18] Unknown:

So are there any cases where you're better off using uWSGI without a reverse proxy like NGINX or Apache?  

[00:17:27] Unknown:

Placing the application server alone on the Internet is always a bad idea.   Okay. Especially, when you have,   blocking app. For blocking, I mean, a multi threaded multi processor app, whereas single request could block   an entire   process or a thread.   So having a proxy,   discarding bad request or long running,   request   in the specific  

[00:17:53] Unknown:

way. So the configuration syntax looks like it provides a very rich set of capabilities. Is it based on a general purpose programming language or is it a DSL that you wrote specifically?  

[00:18:03] Unknown:

It's a DSL.   We started implementing something with Lua   but,   I don't think   there is much more interest in doing it as when you start   making too much   complex configuration,   it's not a good idea.   So   the simple   construct we have   in   the actual DSL is more than enough.  

[00:18:31] Unknown:

So you mentioned briefly that the fast router supports HTTP 2 or the speedy protocol. And for anybody who   is trying to make their app work well with HTTP2,   particularly in the Python space,   what would be the best way for them to do that? I know that WSGI as a protocol doesn't currently support it, but are there any ways that people can   make their app compliant with the new with that new specification?  

[00:19:00] Unknown:

Unfortunately,   until we   we don't fix WSGI,   there is not much space for HTTP 2. Unfortunately,   improving WSGI   is a really   complex topic.   There have been already   4 attempts   in,   in updating it.   Every time, all that goes wrong,   people go to those tests, and so on. It's really   it's it's really a problem   problem with without any solution   so I really   I don't know how to answer these questions because every time someone try to brew whisky, bad things happens.  

[00:19:43] Unknown:

Yeah. The the benefits and the  

[00:19:46] Unknown:

the best thing you can, you can get from trying to from proposing to eat from whiskey is some kind of insult.  

[00:19:56] Unknown:

The the power and peril of having a well adopted standard.  

[00:20:02] Unknown:

Yeah.  

[00:20:03] Unknown:

So what are some of the new capabilities that we can look forward to in the future of uWSGI?  

[00:20:09] Unknown:

I think the most awaited 1 in that's already available in, 2.1,   the master on GitHub,   is the integration with Docker. So an emperor can spawn a Docker container with a single line of configuration.   Even on demand, so you can spawn your Emperor on a socket   and, the first request on that socket, a new container will be new Docker container will be spawned.   We have, much improved,   offloading   so a bunch of new plugins are being developed for using it.   I think mainly new feeders will come in the form of a plug in because we are trying to make the call email,   more tinny.  

So I have no idea of, third party developers,   what they're trying to do.  

[00:20:57] Unknown:

Yeah. Maybe we'd like to do something regarding Internet of Things.   So we'd like to adopt   support those new protocols that are being developed on on that side,   and maybe UWSGI can be a very useful tool in on that field too.  

[00:21:16] Unknown:

And so   given   the dynamic   load balancing in terms of being able to add and remove nodes and what you just mentioned of the Emperor being able to spin up Docker containers. It seems that uWSGI is pretty well positioned to   remain relevant and perhaps even grow in relevance given the   trends that we've been seeing in modern infrastructure.  

[00:21:41] Unknown:

Yeah. Absolutely.   That's in, constantly   adding of new layers in, web deployments,   so having something that can manage them,   simplifying the process of spawning new daemons, managing them,   giving tools   to automatically scale and so on, it's,   it's a good thing.  

[00:22:02] Unknown:

Are there any situations where using uWSGI is the wrong  

[00:22:07] Unknown:

choice?   Oh, well, I think if you start learning Python   or or mainly   web Python web framework, you can be scared by the not so good documentation of, uWSGI.   Or Better than not so good, I will say massive,   over broken documentation   that really could scare a newcomer   and then we will end with people blaming,   the the development the deployment in the Python world and that PHP is better in that area   in these funny   sentences.  

[00:22:43] Unknown:

Yeah. I can definitely attest to being intimidated by the massive set of different configuration options available when when trying to set up some UUID instances.  

[00:22:53] Unknown:

I have to admit that from   this,   point of view, it's not very Pythonic.  

[00:23:01] Unknown:

So it sounds like there's some room for somebody to come in and contribute to documentation with   a getting started guide of these are the minimal set of configuration flags that you need to worry about so that somebody can   have a more gentle on ramp   to using the tool.   So   following that topic, what are some of the areas   that the that you're looking for with help in the project that the community can contribute to?  

[00:23:31] Unknown:

Okay. So I think we can use that,   like in, tragic bugs   because we usually have a quite   a few issues,   filed which are not exactly bugs, but,   request for help.   Also, we have quite a bit of duplication   in GitHub issues,   actually.   So any help regarding that is   much appreciated.   Then on top of that,   we run   often   a Coverity scan of   a whiskey,   and, we have quite   a few bugs still to fix.   So   if anyone is   looking for,   like, some   quick   hack   over   interesting codebase   and no see   and you're not scared.   It's very welcome to help us fixing quality   spotted issues.  

And, I think,   also, we can use help, like in   helping   people with issues   on the mailing list.   So everything that   helps   fellow developers   is welcome   and needed.  

[00:25:02] Unknown:

So before we move to the picks, are there any questions that I didn't ask that you think I should have or any topics that you want to talk about?  

[00:25:10] Unknown:

I don't think so.  

[00:25:11] Unknown:

No. It seems fine.  

[00:25:14] Unknown:

I'd like   to ask,   maybe to you   guys   regarding,   we talked before about   HTTP 2 and   the WSGI protocol.   Mhmm. So I'd like to ask, do you think that   Python is   losing ground   in the web space,   like, against the systems like Node or Go?  

[00:25:45] Unknown:

I think that   the threat   from Go in particular   has more to do with the multi core support than it does with the   HTTP2 support just because   the HTTP2   standard is still so new that I don't think   there are as many people who are focusing on that problem at the moment and trying to make their applications compliant with that specification.   But if we don't do something   in the near future about it, then I think it could end up growing to be a bigger problem.   So I think I know   while I was doing some research for the show, I was searching around about   HTTP2 support in the WSGI protocol, and I came across a couple   of draft specifications   trying to   figure out how to upgrade   WSGI   to support some of the newer web capabilities.  

And so I think that   bringing focus to that   in the larger community and how important that is to the future of Python, I think is really valuable.   So I definitely encourage anybody who has the capability or interest to   improving that specification and improving that capability.   I think it's definitely a very good use of your time in terms of helping the Python community   improve   and stay relevant.   So with that we will move into the picks.   For my first pick today,   I'm going to choose   the Kontakt application in KDE,   which is   their integrated suite for managing your calendar, email, and notes. And it's just a really well put together application, has good integrations   between   all the different features within it, as well as with the larger KDE desktop.  

So I was using   I started off using the Gmail web applications, and then I tried out Thunderbird for a little while. And Thunderbird was just really laggy. And so I ended up trying Contact and have been enjoying it so far.   For my next pick, I'm going to choose Manjaro Linux,   which is the distribution that I've been using for the past couple of years.   I was using Ubuntu and got tired of the 6 month upgrade cycle and   always having my PPAs broken and not being able to use them anymore. So I wanted to move to a rolling release distribution,   and Manjaro is just a   really nicely put together   distro. It has all the advantages of Arch Linux but adds   some polish to it to make the installation and startup   a lot simpler for people who aren't   as hardcore Linux   users. And for my last pick I'm going to choose the movie Black Hat with Chris Hemsworth that I watched recently.  

It's a good movie. It has a good story line, and they actually did a really good job of maintaining   of being factual in their representation   of the use of technology within the movie.   So they didn't have the typical   hacker   depiction of somebody just bashing away on a keyboard and doing magical things instantly. They were much more down to earth and realistic about   how the technology was used in the storyline. So definitely recommend that for anybody who's interested.   And with that, I will pass it to you, Ricardo.  

[00:29:16] Unknown:

So first, I have a book recommendation.   It's, Building Microservices   by Sam Newman,   published by O'Reilly.   It's,   like the title say, it's about microservices,   of course,   but it's not about implementing them, it's more about,   the architecture   and,   all the issues   that, you'll find   when starting deploying   or think thinking about deploying microservices   architectures.   And then,   well,   today,   I've kinda released   Django plug in,   Django application called   Django,   dashdennis,   which you can find   on my GitHub account.   It's like a small application,   but,   it's   recovering   deleted data   from a backup DB.  

So   it's   still in its infancy, but   hopefully, in the next few days would be,   quite useful, I hope.  

[00:30:27] Unknown:

Adriano, what have you got?  

[00:30:29] Unknown:

Well,   I've been thinking to   this kind of things,   but I really have a lot of things,   but nothing like   those you proposed.   I'm gonna search it back.  

[00:30:43] Unknown:

You can share anything you want. There's no restrictions here.  

[00:30:46] Unknown:

Yeah.   I I wanna share the story of Paxos.   Paxos is a distributed system protocol that has a really curious story   because it's solar that is well known in   the distributed systems world that is is Leslie Lamport during the world in, I think, 2014.   Didn't want it to be   boring as all these algorithms   and stuff that can just sedate the the reader. And so he built upon it a whole story about this   lost island in Greek Greece,   where someone found   a very old story   of those in evidence, those native people that   use   a very strange protocol to   to to live   to to live democratically.  

And,   this paper was so strange that at first, it was denied. It wasn't published,   and then after many years, it has been published. And   it's 1 of the most well known   paper in the distributed systems field.   I'm gonna put the link.  

[00:31:58] Unknown:

Yeah. The Paxos algorithm is definitely very interesting both for how well it   functions in distributed systems and for, as you said, the backstory of how it was created and came to be known.   Do you have any other picks?   No. Thank you. Okay. Roberto, how about you?  

[00:32:16] Unknown:

I would like to increase the level of the discussion in this series,   the brink, the Jack Black. I don't know if you know it.   Really fun.   I don't know if it's really fun because sometimes I think it's   depicting   something that is really happening   So   I strongly suggest you to check it. Alright. So  

[00:32:43] Unknown:

as I said before, I really appreciate you all taking the time out of your day to join us and tell us all about uWSGI.   For anybody who wants to learn more about the project or or follow you guys and what you're up to. What would be the best way for them to do that?  

[00:32:58] Unknown:

For support, I think the mailing list I think the mailing list is the currently the best, place to ask for   help. Eventually, the IRC channel,   sharp the uWSGI on free node   and obviously if you want to contribute to make a pull request,   on GitHub,   Ricardo will try to reject it but I can   assure you I will check   it.  

[00:33:24] Unknown:

And for anybody who wants to follow you individually, how can they do that?   And, Adriano, how how could people find you online?  

[00:33:31] Unknown:

Yeah. I'm gonna put my GitHub account.  

[00:33:34] Unknown:

Okay. So for everyone listening,   you are Aldur,   a l d u r, on GitHub.  

[00:33:41] Unknown:

Yeah. Thank you.  

[00:33:43] Unknown:

And Roberto can be found at unbit   on Twitter.   And, Ricardo, how about you?  

[00:33:50] Unknown:

I have a GitHub account, which is,   xrmex,   and the Twitter account is   rmistaken.  

[00:34:05] Unknown:

Okay. Alright. Well, I hope you all enjoy the rest of your evening, and I really look forward to digging into some of the new features that you mentioned in uWSGI.  

[00:34:14] Unknown:

Thank you. Thank you. Thank you for asking. Thank you. Have a great night. Bye. You too. Bye. Bye. Have a nice day. Bye.