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
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
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
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.
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
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 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.