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")
Note: The “magical” tool for XFS is (obviously) xfs_repair. Having it running can sometimes be the tough issue.
Introduction
How could a filesystem corruption happen? There are a couple of likely causes to it:
-
Kernel bugs: they are infrequent but they also did happen many times in the past and will still happen in the future. Not many things to be done about them, other than applying patches / keeping the kernel up to date;
-
Memory issues, e.g. memory errors propagated to the file system in control structures: they are usually mitigated with ECC memory but they can never be ruled out;
-
Underlying storage issues: quite unlikely but nevertheless possible;
-
Using the reset button on running servers: journaling file systems are almost always able to recover from such incident;
-
RAID controller issues: this could be the leading cause and not be easy to mitigate, even if firmware upgrade is sometimes possible.
Note: This is a text about the project work at one of my previous employments.
Introduction
These days everybody talks about Agile, Automation, DevOps and Continous (whatever), without truly understanding why things have gone in this direction. After all, for many years, a software project had a couple of well-known steps that needed to be followed, like:
-
Full, thorough planning at the very beginning and from time to time, before significant milestones;
-
Development, lots of development behind closed doors;
-
Lots of manual QA work, little automation with some custom-written testing framework written from scratch by one of the developers;
-
Infrequent releases (e.g. every year or even every other year or so); releases were thoroughly prepared and tested, with code freezes for (sometimes) months before the Day.
Even if everybody knows these days that such approach may have been a bad way of doing things, it actually worked for many years because that was the way the world expected things to work. There were many constraints, e.g: