As I was randomly browsing through some site optimization content, I got this suggestion that I should use a “modern” image format such as “webp” to get lower image sizes and implicitly speed up page loading time. I can’t say it made a lot of sense to me that very moment, thus the rabbit hole I have soon found myself going into.
1. Introduction
To sketch out some context, the well-known imge formats such as “jpeg”, “png” or “gif” are with us for 25 years or more; they were put together in a time when both storage and cpu processing power were premiums rather than commodities. That meant accepting compromises and precise product-market fits: “jpeg” became the universal format for everyday pictures, “png” for icons or computer generated images and “gif” was mostly delegated to short animated sequences once the patent covering the corresponding compression algorithm expired in the early 2000s.
Modern Python offers powerful features such as asynchronous programming (using async and await) and memory-efficient data processing with generators and iterators. Leveraging these advancements, primarily found in Python 3, can significantly improve your code’s performance and maintainability. This often necessitates migrating existing Python 2 projects. The migration process can vary from a straightforward conversion to a substantial refactoring. To help you navigate this, we’ll discuss some of the crucial differences between the two Python versions.
1. PRINT:
This one is easy – most of the time it’s just about translating code from:
print "abcd";
to:
print("abcd")
You don’t get to explicitly use Linux namespaces very often; one usually gets to make use of them when setting up containers or some sort of smart web hosting platform that allows hard resource limits to be put in place for customers, but even then the actual setup is hidden somewhere in the back. There are scenarios when containers simply require too much work for the particular task; I, at one time, faced the need of ensuring some network communication between 2 instances of the same service.
Communication? Same service? Have them listen on different addresses or on different ports and you’re done, you might say – but it’s not always that simple. If you have no control over the code but just want to replicate a certain behavior, there may simply not be an option to have instances listen on different ports. If the protocol also involves broadcasting, things become really complicated, as you don’t always have 2 IP addresses, on different interfaces, connected to the same network. Such scenario is easy to solve with virtualization or containers, but for this particular problem they’re overkill. The lightweight solution comes from manipulating Linux network namespaces.