In my last article, I explained how our communication with the backend takes place and how we were able to build a very simple caching mechanism thanks to signals. In this blog post, I would now like to demonstrate how we use the signals from our services within the components. Views As mentioned in the previous post, we have, broadly speaking, “Views” and “Actions” for displaying data from the backend. In the Views, primarily only data is presented, and in Actions, this...
After explaining in the last blog post what Angular Signals are and how they are used, I would like to delve into how we at calitime.ch handle Signals to keep our tool TimeRocket soaring through the cosmos in this article. We don’t use HTTPClient! First and foremost, I must start with a circumstance that may not be common for many teams using Angular: We do not use HttpClient (anymore).Normally, HttpClient is the preferred tool in Angular to make HTTP requests to a server. It returns...
What are Signals? On May 3, 2023, Angular 16 was released, introducing the possibility to use Signals. Signals are another way to implement the reactive programming paradigm in Angular. For quite some time, RXJS has been available for this purpose, and it doesn’t seem to be disappearing from the Angular world anytime soon. Generally, the current consensus is that RXJS should be used for more complex problem scenarios since it is more powerful but also harder to grasp. However, for simpler...
After one of my presentations about F#, we had a discussion about the effect of type inference, resulting in almost no type annotations, on code readability and reviewability. The concern was that it makes the code harder to understand, especially when reviewing code, for example, outside of an IDE (GitHub/Azure DevOps/… Pull Requests).
So is there a problem or not? Let’s see.
Yesterday, I found myself face-to-face with a rather peculiar phenomenon that managed to consume a good hour of my time. As is often the case, the solution turned out to be surprisingly simple. With the intention of documenting this for future reference (especially for my future self), I am writing this short blog post. What happened? A colleague of mine updated XUnit in our solution and merged it into our main branch. When I pulled the new code locally and tried to restore the NuGet packages...
In this blog post, I describe the way we currently work as a team to deliver our product (TimeRocket) to our users and customers. This reflects our current understanding of working in an agile* way that matches our needs and skills. We are uncovering better ways of developing software by doing it and helping others do it. Manifesto for Agile Software Development (agilemanifesto.org) As the manifesto for Agile Software Development states, we continuously try to improve our way of working, so...
Sometimes, unit tests are really small – so small that they fit on a single line:
In F#, you specify the order of files explicitly. Any code can only reference types, modules and functions that are higher up in the same file or in a file higher up in the file list. When starting with F#, this feels strange because most programming languages don’t rely on ordered files. Some call this feature even dumb.
A recurring claim is that OOP languages, in general, are faster than FP languages – or specific to .Net, C# is faster than F#. So today, we take a look at the myth about F# being slow.
We use NodaTime in our application to deal with time. As you may remember, time is very important in our application – it’s a attendance time-tracking tool with duty planning and many more features. For example, we use Instant to model a point in time. But sometimes, we need a point in time with a granularity of minutes, not nanoseconds. Instead of introducing our own type to model an instant with minute granularity, we use an Instant with a measure. Let’s see how this works: