Angular offers a way to separate an application into modules. There are many ways to group functionalities into modules and the decision is left to the programmer to find the best composition for the application. For example, a module can group a part of the application domain logic, or it can also serve as a grouping for reusable directives, or a grouping for providers. I have describe briefly about two years ago what a module is in Angular looking into the details of the NgModule decorator. Today I will dive into more details on how to separate an application into feature modules and what doing so provides us.

Last week we looked into the definition of a Dockerfile. We saw that a Dockerfile describes how an image will be built, the next obvious step is to dig into the building process of the image by looking at the logs and exploring the image layers.

Docker images package all the necessary pieces to run an application, the operating system, the application runtime, the environment and the application binaries into a reusable snapshot. To create a Docker image, we use a Dockerfile which specifies instructions to build the image. Docker images can be based on other Docker images which makes them reusable and allows us to delegate the tedious setup of an operating system with application runtime to others. Today we will explore the composition of a Dockerfile and look into examples in order to get an understanding of the set of instructions at our disposal to build a Docker.

One thing that I had a hard time to understand when starting to work with Typescript was the differences between Type and Interface. Even after working with TS for quite some time it can be difficult to see the benefits and interesting combinations one can provide over the other. Tslint is very helpful in that regards with a set of rules enforcing the use of the right definition. So today we will look in more details on the differences and the benefits of Type and Interface.

In previous blog posts we looked into features of Angular. The language used to code Angular is Typescript - a superset of Javascript, and Angular itself relies heavily on the features of Typescript but also NodeJS libraries. When it comes to testing functionalities completely unrelated to the browser or even the website itself, it is good to have an easy way to design a piece of logic with functions, classes, and module and execute it directly using Node rather than having to bundle it within an Angular SPA. With that idea in mind, today we will look into how to setup a simple project running Typescript code which will allow us for example to test functionalities of rxjs without the need to bootstrapping a frontend project.

When working on open-sourced projects, it is common behavior to fork a repository. The fork repository is a replica of the main repository with the only difference being that it is under our own ownership and is separated from the original repository. That allows us to make changes to the project without impacting the main repository. This scenario is very common for contributions where we make commits on our fork repository and later on submit a pullrequest against the original repository. But after having forked the repository, our own copy no longer gets new updates from the original repository. Today we will see how we can setup a forked repository to continue getting the latest commits from the original repository.

The OpenAPI Specification (OAS) is a standard describing the interface of restful APIs. It provides a way for developers to understand quickly the functionalities provided by an API, and also provides a way to automate tasks around discovery, testing and also generation of client SDK in multiple languages. Each language plus web framework combination provides some sort libraries enabling auto-generation of the OpenAPI specification, for example in DotNetCore we have Swashbuckle.AspNetCore or in Python with Flask we have Flasgger. Today we will take the opposite idea to auto-generation and craft the specification by hand. The technology agnositic aspect of the OpenAPI specification makes it an incredible tool to design APIs and brainstorm at the interface level prior writing a single line ofe code. We will look into what constitute a specification and how we can arrange the specification in a human friendly way.

Postman is a free development tool which helps testing API. It provides a complete API testing desktop application allowing us to create requests, organise them in collections and write test assertions while also providing variables management at different levels, environment level, collection level or request level. On top of that, it can easily be integrated into our automated CI using Newman, the CLI for running collections.

In Angular, Pipes are used to specify operations directly on the HTML template, operating directly on the value prior being embedded to the template. The major benefit of pipes is their simplicity, using them we are able to remove abstract out logic which we would otherwise reside in the component. In a previous post, we discussed the AsyncPipe used to subscribe to observables. Today we will see the rest of the pipes available in Angular and how they can be used:

Minio is a open source distriubted storage. Few weeks ago, I showed how we could use it to store Microsoft Orleans actor states by implementing a grain storage backed with Minio. Today we will see how we can install two parts of Minio, the Minio server and the Minio client and we can update it when need be.

We recently looked into a simple metacircular evaluator interpreting a part of Lisp. We saw that it was possible to reimplement some of the functionalities by parsing Lisp expressions. We also saw that by slightly changing the order of application, we were able to turn our language into a lazy language. Today we will look into nondeterministic evaluation, also called ambiguous evaluation, another concept which can be made available to the language by re-modeling our evaluator in the same way as we did to introduce laziness.

Last week we implemented a metacircular evaluator in Racket, evaluating a subset of Racket language. We saw that the main functions part of an evaluator are eval evaluating the meaning of an expression and apply, applying a procedure to arguments. We wrote the evaluator following the order of execution of arguments and procedures from Lisp. Lisp being an applicative-order language, when provided a procedure with parameters, the parameters get evaluated before the procedure is applied. As opposed to normal-order languages, also called lazy languages, which delay the evaluation of arguments until the result of the procedure application is required. Today we will see the implication of this slight change in order of application by modifying our evaluator created last week, transforming it into a lazy evaluator.

In previous posts, we explored the concepts of abstraction, mutability, and closure. A common point to all of them is that they were made available by programming languages. In fact, programming languages can themselves be seen as a very low level abstraction composed by a set of expressions. A programming language is written by composing functions together, like any other program, and interpreting the meaning of expressions given. Today we will look at how we can create an evaluator by implementing a metacircular evaluator supporting a subset of the syntax of Lisp.

Dynamic programming (DP), is an algorithm design technique used to turn exponential complexity problems into polynomial complexity problems. Described as careful brute force (Erik Demaine - MIT course 6.006), problems are deconstructed into overlaping subproblems, solved indepedently with brute force, subproblems solutions are then cached and reused. The reusability aspect being a major contributor to the optimization due to the overlapping nature of the subproblems.

In a previous post, we saw how we could host an ASP.NET Core application behind Nginx. We saw that Kestrel works as a selfhost webserver and that in order to get request forwarded to it, we need to proxy them using the location and proxy_pass directives. Today we will look into some details regarding path handling, ensuring that our requests are forwarded properly.