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.

The stash is the place where we can save work in progress from working tree and index while reverting to the HEAD commit, a command useful to pull latest on the checkout branch or simply inspect other branches. In this post we will look at how to use git stash.

Git log is a command used to look at the commit logs. It’s a useful command to look at the history of a repository, the different commits, the different merges or even the repository graph. In today’s post we will look at few example where git log can be used.

In few of our previous posts, we referred to the HEAD, working tree and index when dealing with Git. In today’s post we will look at what those mean with example.