This is my thoughts after reading Don’t Look Down on Print Debugging. TLDR Print debugging is a tool, and it has its uses - however, if there are better tools available, maybe use those instead. For me, a better tool is OpenTelemetry tracing; it gives me high granularity, parent-child relationships between operations, timings, and is filterable and searchable. I can also use it to debug remote issues, as long as the user can send me a file....
One of the many reasons given for using microservices rather than a mono repository is that it enforces boundaries between services/modules. However, there are ways to achieve strong boundaries between modules/services in one repository, using tools which are already available: test runners. Given a repository with the following structure: . ├── libraries │ ├── core │ ├── events │ └── ui ├── services │ ├── catalogue │ ├── billing │ └── shipping └── tools └── admin-cli There are a few rules we should enforce:...
In my previous post, I glossed over one of the most important and useful parts of Immutable Infrastructure: Testability. There are many kinds of tests we can write for our infrastructure, but they should all be focused on the machine/service and maybe it’s nearest dependencies, not the entire system. While this post focuses on testing a full machine (both locally in a VM, and remotely as an Amazon EC2 instance), it is also possible to do most of the same kind of tests against a Docker container....
So this is a bit of a rant…but hopefully with some solutions and workarounds too. So let’s kick things off with a nice statement: I hate broken builds. So everyone basically agrees on this point I think. The problem is that I mean all builds, including ones on shared feature branches. Currently, I work on a number of projects which uses small(ish) feature branches. The way this works is that the team agrees on a new feature to work on creates a branch, and then each developer works on tasks, committing on their own branches, and Pull-Requesting to the feature branch....
We have a test suite at work which tests a retry decorator class works as expected. One of the tests checks that when the inner implementation throws an exception, it will log the number of times it has failed: [Test] public async Task ShouldLogRetries() { var mockClient = Substitute.For<IContractProvider>(); var logger = Subsitute.For<ILogger>(); var sut = new RetryDecorator(mockClient, logger, maxRetries: 3); mockClient .GetContractPdf(Arg.Any<string>()) .Throws(new ContractDownloadException()); try { await sut.GetContractPdf("foo"); } catch (Exception e){} logger....
I gave a little talk at work recently on my use of Vagrant, what it is, and why it is still useful in a world full of Docker containers. So, What is Vagrant? Vagrant is a product by Hashicorp, and is for scripting the creation of (temporary) virtual machines. It’s pretty fast to create a virtual machine with too, as it creates them from a base image (known as a “box”....
We have a service which consumes messages from a RabbitMQ queue - for each message, it makes a few http calls, collates the results, does a little processing, and then pushes the results to a 3rd party api. One of the main benefits to having this behind a queue is our usage pattern - the queue usually only has a few messages in it per second, but periodically it will get a million or so messages within 30 minutes (so from ~5 messages/second to ~560 messages/second....
When building libraries, not only is it a good idea to have a large suite of Unit Tests, but also a suite of Integration Tests. For one of my libraries (RabbitHarness) I have a set of tests which check it behaves as expected against a real instance of RabbitMQ. Ideally these tests will always be run, but sometimes RabbitMQ just isn’t available such as when running on AppVeyor builds, or if I haven’t started my local RabbitMQ Docker container....
The trouble with testing containers is that usually the test ends up very tightly coupled to the implementation. Let’s see an example. If we start off with an interface and implementation of a “cache”, which in this case is just going to store a single string value. public interface ICache { string Value { get; set; } } public class Cache { public string Value { get; set; } } We then setup our container (StructureMap in this case) to return the same instance of the cache whenever an ICache is requested:...
Often when developing something, I have the need to check how a function or library works. For example, I always have to check for this question: Does Directory.ListFiles(".\\temp\\") return a list of filenames, a list of relative filepaths, or a list of rooted filepaths? It returns relative filepaths by the way: Directory.ListFiles(".\\temp\\"); [ ".\temp\NuCrunch.Tests.csproj", ".\temp\packages.config", ".\temp\Scratchpad.cs" ] Now that there is a C# Interactive window in Visual Studio, you can use that to test the output....