I'm currently in the process of adding asyncio support to my Socket.IO server. Being experienced in the eventlet and gevent way of doing async, this has been a very interesting project, and a great learning experience. At some point I reached a head scratching moment, when I tried to write some unit tests to exercise the new code I was writing, but found that the Python unittest and mock libraries do not offer any facilities specifically tailored to testing asyncio.

One of the aspects I'm most proud of regarding my Socket.IO server is how complete the unit test suite is, in spite of being a highly networked project that runs under multiple asynchronous and networking frameworks. Given the high complexity of this project, I considered it a requirement to properly test all this new asyncio code, so I spent some time thinking about ways to implement asyncio testing. In this article I want to share the solutions I came up with, which helped me reach 100% coverage of my asyncio code.

Highly distributed applications that consist of lots of small services talking among themselves are getting more and more popular, and that, in my opinion, is a good thing. But this architectural style brings with it a new class of problems that are less common in monolithic applications. Consider what happens when a service needs to send a request to another service, and this second service happens to be temporarily offline, or too busy to respond. If one little service goes offline at the wrong time, that can create a domino effect that can, potentially, take your entire application down.

In this article I'm going to show you techniques that can give your application some degree of tolerance for failures in dependent services. The basic concept is simple: we make the assumption that in most cases these failures are transient, so then when an operation fails, we just repeat it a few times, until it hopefully succeeds. Sounds easy, right? But as with most things, the devil is in the details, so keep reading if you want to learn how to implement a robust retry strategy.

Every time I find myself writing code to delete data from a database I get nervous. What if I later determine that I needed this piece of information, after all? For example, what if having access to this data that was deleted would have helped me reproduce or debug an issue? Or what if the data can be useful for audit purposes in a future version of the application?

You can find lots of reasons to never delete records from your database. But obviously these records that you saved from permanent deletion need to be marked as being "less interesting" than the rest, so that you have something you can use to filter them out in queries. The Soft Delete pattern is one of the available options to implement deletions without actually deleting the data. It does it by adding an extra column to your database table(s) that keeps track of the deleted state of each of its rows. This sounds straightforward to implement, and strictly speaking it is, but the complications that derive from the use of soft deletes are far from trivial. In this article I will discuss some of these issues and how I avoid them in Flask and SQLAlchemy based applications.

Many times I hear people say that user sessions in Flask are encrypted, so it is safe to write private information in them. Sadly, this is a misconception that can have catastrophic consequences for your applications and, most importantly, for your users. Don't believe me? Below you can watch me decode a Flask user session in just a few seconds, without needing the application's secret key that was used to encode it.

People are always curious about what I do at work. Up until some months ago, I was employed by Rackspace and worked on OpenStack development, something that made total sense and required no additional explanation. But then, in November of 2015 I decided to leave Rackspace to join an unknown little startup called SDVI Corporation. I have been working with them since.

I am constantly asked what is this SDVI thing, so I decided to put it in writing. Now, in the spirit of full disclosure, this isn't a completely innocent idea. SDVI is growing and is hiring full-stack developers, so with this article I not only want to satisfy your curiosity, but also pitch the company to those of you who might find that what we do is interesting.

UPDATE: I'm leaving this article up, but note that as of October 2016 I have left SDVI. If you are interested in applying to one of their jobs, please contact them directly, I am not involved with this company anymore.

The tutorial line up for PyCon 2016 in Portland, Oregon has been announced, and I'm excited to be part of it with yet another Flask tutorial. For some odd reason, not all the class information I provided with my proposal was published on the PyCon website, so I want to give you a good overview of the material I plan to cover here, to help you decide if this tutorial is for you.

Below you can find the video of a talk I gave yesterday at the Python Portland user group meetup. The topic of the talk is error handling. Note that I recorded the talk myself, using a screen capture software plus a voice recorder app running on my cellphone. It is a decent recording, but not professional quality by any means.

I want to thank the PDX Python user group for giving me the chance to present last night, and also to my employer SDVI Corporation for sponsoring the night and bringing in pizza. By the way, did you know SDVI is hiring remote Python/Javascript developers?

If you work on a project that uses database migrations with other developers, it is likely that you have experienced migration conflicts at some point. These occur when two or more developers are merging unrelated features to the master source control branch at around the same time, with each feature requiring different changes to the database.

In this article, I'm going to describe the problem and its solution in detail, using an actual example based on my Flask-Migrate extension. While I will be using commands that are specific to Flask-Migrate and Alembic, the solution to the problem that I present here can be adapted to other database migration frameworks.

The Flask response class, appropriately called Response, is rarely used directly by Flask applications. Instead, Flask uses it under the covers as a container for the response data returned by application route functions, plus some additional information needed to create an HTTP response.

What's not widely known, is that Flask gives applications the option to replace the stock response class with a custom one, opening the door to some neat tricks. In this article I'm going to show you how to take advantage of this technique to simplify your application code.

Microsoft Windows has long been considered a subpar platform for web development not based on a Microsoft technology, or in more general terms, for any kind of open source work. If you are looking for tutorials online on any open source related topic and happen to be on a Windows PC, you are going to have a lot of trouble in finding material that does not assume you are on a Linux or Mac system with access to Unix-based tools.

I mostly work on a Mac computer these days, but I own and regularly use a Windows PC as well. In this article I'm going to introduce you to the open source project that I use to bridge the gap between Windows and the Unix world. This project allows me to work on my open source projects on the PC, using the same tools I use on the Mac, or on a Linux PC. The image above is a screenshot of my terminal, running on Windows 10 (click on it to see it in its actual dimensions). There you can see I have three independent very Unixy-looking console sessions. Not the type of terminal window you associate with Windows, right?