Angular Router reuses components when it sees fit. The act of reusing a component saves time as the framework doesn’t need to destroy and create back a new object, instead it emits new values onto the observable params and data of the route. In today’s post we dig into the details of when does the reusability of components take place and understand how it impacts route.data.

Change detection and DOM rendering are functionalities handled by Angular framework. When we build applications, most time, we don’t really need to pay attention in how things gets rendered as we trust Angular to do its job. But in some cases, it is necessary to understand how the rendering work, for example when using test tools like Cypress which gets instances of DOM nodes to perform action on them. We can get into situation where the re-rendering of arrays detach DOM nodes which were used by our Cypress specification. In today’s post, we will take a look at how the DOM get updated by Angular when re-rendering nodes on component input updates.

Few months ago we talked about Python Unittest. We looked at it from the perspective of running from terminal which is a great way to quickly verify that our application is healthy. When it comes to debugging specific issue, running from terminal can be more tricky. In this post, we will look at how we can enable Unittest test discovery from Visual Studio Code with the Python extension in order to provider a quick and easy way to debug source code and allowing us to breakpoint in unit tests.

In previous post we looked at ViewChild which gave access to the elements within the view, and ContentChild which gave access to the elements within the decorated directive. Combining those two allows us to create reusable components flexible enough to allow users to define their contents. For example, creating a table component where we abstract away the way a table is constructed and the style applied to it, but leave fuill flexibility for the user of the table to define the content of each cell. In this post, we will look at how we can create a reusable card component which defines the look of a card but leaves the full control to the user to define its content.

Even after using SQL for years, I still get caught from time to time with join cardinality where the result of simple queries surprise me as I omit to consider the relationships between tables assuming one-to-one relationships. In this post, we will look at the different type of joins that Postgres supports and see how the cardinality affects the result.

In previous posts, we looked into how compilers worked in general and dived into Python in particular looking at how CPython was producing Bytecode which in turn was interpreted by the Python VM. In the world of Ethereum blockchain, smart contracts are the programs that run on the Ethereum VM (EVM). In the same way, smart contracts are compiled into Bytecode which are submitted to the blockchain, and end up being executed on each nodes the decentralized Ethereum blockhain. In today’s post we will be building an example of a smart contract written in Solidity and deploy it in a local Ethereum blockchain.

Few weeks ago we talked about setuptools and setup.py. We demonstrated the configuration of a simple setup.py file in order to package a project. Although setup.py used to be the default way of packaging applications, Python has progressed to offer a more generic approach described in PEP 517 and PEP 518 with the pyproject.toml file. In today’s post we will look at the usage of pyproject.toml in the context of package management.

When writing unit tests, we sometime must mock functionalities in our system. In Python unittest.mock provides a patch functionality to patch modules and classes attributes. In this post, we will look at example of how to use patch to test our system in specific scenarios.

Few weeks ago we looked into CPython, the default implementation of Python. We saw that CPython is implemented in C and provides a way to declare extensions implemented in C to be used from Python. In this post we will look into a simple example of a module implemented in C and see how we can use it from the Python interpretor.

Application profiling allows developers to understand the performance and resource usage of an application. It can be used to identify hot paths or simply to explore what an application does. Today we will look at a way of capturing CPU samples for Python applications with py-spy and how to understand the resulting profiling data with speedscope.

During the development of a Python application, we interact with tools like pip and libraries like setuptools. Pip allows us to install packages while setuptools is a library built on top of distutils providing necessary tools to package and distribute our own application. Python supports two types of distributions, wheels and source distributions. In today’s post we will look at the usage of both of them and also look at how we can create them oursevles for our own application.

Last week we looked at CPython and mentioned that the interpretor was a stack based virtual machine. In today’s post we will go into more details why we mentioned that the VM was stack based by looking at the dissassembled Bytecode and compare it with a assembly code runnable on a register machine.

Last week we looked at how compilers worked in general. We saw that they were mostly composed of two parts, the front end and back end. The front end being the compiler from programming source code to intermediate representation and the back end being the runtime. In today’s post we will look specifically into how Python gets compiled and interpreted with the default implementation, CPython.

With the recent introduction of Apple M1 chip, we have seen the start of the adoption of the ARM processor architecture for Apple Macbook line. ARM being a different family of instruction set architecture than x86 (most common as of today), this means that any application built for x86 (for Mac with Intel or AMD chips) needs to be recompiled to run on ARM (M1 chip). The process of compilation is a multistep process starting taking code written in programming languages and transforming it into machine code understood by the processor. In today’s post we will look at the different part involved in the compilation process.

Few weeks ago we talked about Git Rebase. We saw how we could use it to manipulate the history of branches. By default, rebasing would flatten all merge commits making the history linear. In today’s post we will see how we can rebase while keeping merge commits.