Have you read “Clean Code” by Robert C. Martin? Then “A Philosophy of Software Design” by John Ousterhout should be next on your list. It shares the same goal—writing better, maintainable software—but sometimes takes a very different path to get there.
While VSCode and DotNet generally works on FreeBSD, the “C# Dev Kit” does not due to the following issue: FreeBSD build of C# Dev Kit
Knowing that FreeBSD jails support running an almost full features linux system and also X11 apps, I was curious whether it would be possible to run VSCode including “C# Dev Kit” in a jail.
Here is what I learned.
What is software craftsmanship?
Craftsmanship is the state of knowing, how to do something well and is the outcome of good tutelage and lots of experience.
– Robert C. Martin, Clean Craftsmanship
I’ve been interested in software architecture, particularly in Clean Architecture, for many years. I discovered this book a while ago and kept it on my reading list until recently, when I finally found the time to read “Get Your Hands Dirty on Clean Architecture” by Tom Hombergs.
One of my web applications has quite some pages which show quite a bit of data.
In order to achieve smooth navigation between the pages, without bothering the user with progress indicators when the data of a page is loaded from the Web API every time the user navigates to a particular page, the data needs to be cached in the browser.
As most of the data is readonly, frameworks like Vuex or similar state patterns seem to be “too heavy” in this case.
Here is my simple approach to automatically cache the response objects from the Web APIs which provides great performance of the Web application without introducing much complexity.
I didn’t investigated it on my own, but some research indicated that Vue.Js performs better when the objects
bound to the UI controls are frozen. Of course, calling Object.freeze manually in every Vue.Js component
is cumbersome and error-prone so here is how I automatically freeze all response objects I receive
from my Web API using Axios.
In the previous article I summarized how I used Docker to host a web application on my Raspberry PI. This successful experiment inspired me to start a new one: Let’s turn this “regular” web application into a Progressive Web App (PWA), only hosted and operating in my local network.
It turned out this experiment was a lot trickier than initially thought …
Even though Docker is popular already for quite a while, I never had an opportunity to give it a try. Until recently when I bought a Raspberry PI to host some web applications.
Of course, hosting these web applications directly on the PI would have been simpler and more efficient but then I still wouldn’t have any hands on experience with Docker.
Here is the summary of my first Docker experiment.
Since I am a software developer, I have been interested in increasing my productivity because there are always more things to learn, experiment with, and accomplish than I could possibly achieve.
Over the last two decades, I have read quite a few books, countless articles, and watched tons of YouTube videos on the subject.
So, when Ali announced his book, it was clear that I would get one.
Everyone is saying: “When you want to learn about the Rust programming language then this is THE book to start with!”
A book about functional design by Uncle Bob?
When I read about a new book by Uncle Bob on X, I was immediately excited because so far I had read almost all of his books and I love functional programming since years. A perfect match!
So I pre-ordered the book already march 2023 and immediately started reading when it finally arrived in january 2024.
If you see such source code, do you immediately think of multi-threading?
What if I would tell you that Task<T> is nothing but a fancy delegate which is not coupled
to threads at all?
Behavior driven development (BDD) and the Gherkin language, first and foremost, are about collaboration and documentation.
The key idea is to specify the behavior of a software system by describing its features using concrete scenarios and examples. By describing the scenarios in the language of the domain and by doing this together with the domain experts, we ensure that each feature is completely covered by its scenarios and that each scenario is specified correctly.
Using this approach ensures that we build the right system.
We write the scenarios using the Gherkin language which is designed to be both, human and machine readable. By parsing the scenarios and automating its steps we turn the specification into executable test cases which verify that the implemented features behave as specified.
Using this approach ensures that we build the system right.
Now, reading raw Gherkin in an IDE is fine when developing and reviewing a particular feature and its scenarios. But when it comes to providing a long term specification, HTML has clear benefits over Gherkin with respect to readability of the scenarios and navigation between features.
For this reason I have added support for generating HTML documentation from Gherkin based feature files to the TickSpec extension TickSpec.Build.
Just recently, I wrote about my BDD approach in one of my projects in this article. I have used this setup now for a while and it actually worked quite well for me but there is one thing which turned out to be quite annoying over time.
