Python decorators explained in 2 minutes

Python decorators seem to confuse most newbies. But in reality they are just a fancy way of wrapping functions and modifying their behaviour as a consequence. They are functionally similar to Java annotations.

The code below describes a decorator in its simplest form.

It can be rewritten as per below, using the pie syntax:

My philosophy about technology architectures

I get asked this question often: how would I build an effective IT strategy in a way that will deliver both short- and long-term business value? I believe that it always boils down to these three mantras:

A. Learn once, write anywhere
This is rule number one. Very similar to the KISS (Keep It Simple Stupid) mantra. Don't spruce up a high variance tech all over the place to sound hip. Go for technology frameworks that do not need isolated niche skills. Instead go for technologies that talent can be easily transferrable elsewhere.

B. Fast deployment and Immutable Infrastructure

You want to scale up (or down!) quickly and cost-effectively? Then you have to build your stack in a way that is easy to adapt to changes and features while catering for growth. Do not grow vertically. Grow horizontally, ideally using commodity hardware. What am I saying here? Look into DevOps philosophies, continuous integration and deployment pipelines.

C. Loose Coupling Technology (don't put all your eggs in same basket)

This is perhaps one of those concepts that if misunderstood, will pave the way to long-term failure. We have all heard about vendor locking, and you already probably know that this can lead to a growing technical debt in the future. One can also transpose this concept to the choice of technology - whether how host your infrastructure, or which tech to use to power and code your application. Bottomline is to avoid technologies that are tightly coupled with specific systems (example: does your current stack work only on NOSQL systems? Can your application be transferred to the cloud?)

If you are like me, you have probably worked on a multitude of different technology stacks, way before they were called "stacks". From Linux to Windows, from open-source to proprietary systems, from monolith to service oriented architectures, etc. One needs to take into consideration other business processes when starting to think what architecture suits you best - consider HR processes, operation processes, marketing processes, etc.

Remember, there is no such as thing as 'best practice' in the real world, but more of a 'best fit'.