A Brief Look At NDepend

I was recently (well, actually it’s more like 6 months ago now at the time of writing… things managed to get away from me!) contacted with an offer to give NDepend a go and see what it can do. As my current day job currently sees me writing C# and using the .NET ecosystem most of the time, I’m always interested in trying out new things.

Setting Up A Jenkins Server On NetBSD

I’ve been working on improving Nim’s BSD support for a little while now, first by adding continuous integration running on FreeBSD and then on OpenBSD. The next step was obvious: running CI on NetBSD. Unfortunately, I couldn’t find any CI services currently offering NetBSD as an option, so off I went down the rabbit hole of setting up a Jenkins install myself on NetBSD. In this post, I’ll run through the process of doing so, as it’s not as obvious as it may be on other platforms.

Parsing Data Packets In .NET

One of the most common tasks that I come up against when using .NET at work is to parse data received via some transport mechanism into a form that can be processed and further handled. Over the years, my approach has changed along with some of the newer APIs that have become available within .NET. In this post, I want to briefly look at the approach I currently take, making use of the <Span<T> type.

Validating strings at compile time

In my previous post, I looked at one way of solving a problem when interfacing with a library that takes a string argument with a list of parameters, such as the pledge(2) system call in OpenBSD.

In that post, we used a list of enum values that we formatted as a string at compile time. There is an alternative approach to this problem though: what if we validated the string we pass at compile time?

Generating strings at compile time in Nim

When working with C libraries, you often find yourself passing strings to functions as a value list. One example of an API like this is the pledge(2) system call in OpenBSD, where the first parameter is a string listing the promises to pledge to.

Working with these string arguments can be brittle and may lead to runtime errors due to mistyped parameters. It would be much nicer if we could pass strongly typed pre-defined values via enums instead, and let the compiler worry about validating the arguments.

C# JSON encoding with System.Text.Json - a small gotcha

Microsoft released a new namespace for working with JSON in .net core 3, called System.Text.Json. I’ve recently spent some time trying it out with a view to moving from Json.NET.

During this experimentation period I hit upon a small gotcha that I thought it was worth documenting, as it affects quite a large amount of code that I’ve written.

Automated Testing for Zig projects with Circle CI

Automated testing is a handy tool for practicing Continuous Integration. There are a lot of different services and platforms available to developers to help automate testing for your projects. In this post, I’ll be exploring using Circle CI to automatically test a Zig based project.

Deploying Hugo on NearlyFreeSpeech.NET with Git

I’ve been hosting this site with NearlyFreeSpeech.NET for a little over 2 years now, and have been using Hugo to generate it for slightly longer. I decided it might be a good idea to dump my setup somewhere so that I can refer back to it at a later date, and since I’m doing so I may as well make the details public as a post.

Continuous Integration for Nim using Circle CI

Continuous Integration is an important and widely used practice when it comes to software development. Over recent years, several projects have cropped up to help provide automated testing and delivery as part of your Continuous Integration system.

Since reading BlaXpirit’s excellent blog post regarding using Travis CI with Nim, I’ve been making use of Travis to build and test several of my open source projects. In that blog post, another Continuous Integration service is mentioned: Circle CI. Circle CI are currently beta testing version 2.0 of their platform, which allows you to run your tests inside Docker Containers. Given that there are official Nim Docker images which target the stable Nim channel (eg: the latest releases) on both Ubuntu Linux (using GNU libc) and on Alpine Linux (using musl libc), I thought that it might be worth taking a look at their offering. After a little playing around, I managed to get tests running against both Ubuntu and Alpine sucessfully.

Using Nim with C# .NET

Nim is a statically typed programming language that compiles to C featuring a tracing garbage collector, zero overhead iterators, and powerful compile time evaluation of user defined functions. It features an indentation based syntax with a powerful AST based macro system. Thanks to the fact that Nim currently compiles to C, it can run on many platforms and architectures via a native binary. Cross compilation (for example, compiling a Windows executable on Linux) is also possible with the correct compiler configuration.

C# is a programming language from Microsoft that is developed as part of the .NET framework. It is also strongly typed and offers multiple programming paradigms, though it is primarily object orientated. Until very recently, the .NET framework was a proprietary framework available only for Windows. With the .NET Core initiative though, Microsoft have started opening .NET onto other platforms including Linux and the Mac. However, many third party libraries (and several first party ones) do not work with .NET Core due to changes that Microsoft made to program structure and configuration.

In this post, I will be exploring how easy it is to use libraries written in Nim within your C# projects. Thanks to the fact that Nim compiles to C, it’s incredibly easy to build a DLL that can be accessed from within .NET. To begin, we’ll write an extremely simple Nim library with a single function that adds two integers and returns the result.

Using Laravel's scheduled tasks with systemd timers

Laravel 5 includes a handy system to create scheduled tasks that are ran through the artisan console. In order to run these command automatically, the documentation recommends using a cron job to call the schedule:run artisan command every minute.

One problem: minimal CentOS 7 installs do not come with cron installed. We can easily replicate this functionality using systemd timers however, without having to install any extra dependencies. The best resource for learning more about systemd timers I’ve found is the Arch Linux Wiki Page “systemd/Timers”, which goes into detail on the different types of timers (monotonic and real time) as well as providing some example unit files.