Dev With Imagination

As part of some experimentation I was doing with Docker Swarm I encountered some inconsistent behaviour in my setup. To rule out inconsistencies in OSs (since I was using a combination of Ubuntu and Debian Buster), I had a look at the install process for Ubuntu on a Raspberry Pi.

The Raspberry Pi which was spare for this experiment was a model 3A+, so no ethernet and only a single USB port. With Raspbian I would have added “wifi_supplicant.conf”¹ and “ssh”² files to configure the WiFi and enable SSH as part of the first boot.

I was looking for a similar approach that would work for a headless Ubuntu install.

I came across this project: Raspberry Pi Cloud-Init for WiFi. This uses the cloud-init system to configure, amongst other things, WiFi. This basically provides a few scripts to generate some additional files to copy on to an Ubuntu imaged SD card.

I did find however that it required a few updates to make it work for me on Ubuntu 19.10.

» Continue reading

Over the past few months I have been expanding the number of smart home devices I have and appreciating how HomeKit allows these to all be managed in a single place, regardless of the manufacturer.

There is one older device that I have which does not support HomeKit, and was only controllable through the App from the manufacturer. HomeKit support for this device is not coming, but there is a workaround.

Enter HomeBridge.

HomeKit support for the impatient.

Homebridge is a lightweight NodeJS server you can run on your home network that emulates the iOS HomeKit API. It supports Plugins, which are community-contributed modules that provide a basic bridge from HomeKit to various 3rd-party APIs provided by manufacturers of “smart home” devices.

There is a docker image available, but the setup instructions for this require the container to be ran with the “host” networking mode. The primary reason for this appears to be to allow an Avahi daemon to run in the container and be able to answer responses to mDNS requests, which requires the container to be in the same local network subnet as the device performing the lookup.

For isolation purposes I’m not a fan of running services in host networking mode, and I already have an avahi-daemon running on my server for advertising other services.

» Continue reading

Lately I have been doing some research into Feature Toggle approaches, and how these can be used in Micro Services components developed in Java. These are simple true/false values used to determine if a given application feature (or code path) is enabled.

On looking at a MicroProfile quick start with sample code, the Config feature specification looked interesting for tackling a piece of this functionality.

The aim here is to provide a proof-of-concept implementation that allows for feature toggles that can be scoped down to different user attributes. This should be able to act as a starting point for a more complicated implementation if required. While it turned out that this could not be done solely using the Config feature, there appears to be a viable approach when combining this with Context Dependency Injection (CDI).

In the interests of speed and simplicity, this will use a header in the HTTP request to define the role of the user. If this approach was to be used in a production environment this role assignment would need to be provided by something which is verifiable, such as the JWT token provided.

All the source code for this implementation is part of my microprofile experiments project.

» Continue reading

It should go without saying that in any piece of development testing is important.

While unit testing can (and should) be used to test the individual components which make up a piece of software, there always comes a point where the software has to have a set of integration tests ran. Mocking of components can allow code to be tested in isolation, however if overdone all that has been achieved is testing the mocks. Integration tests should be ran in as close to a realistic deployment as possible, as the more differences which exist between the test environment and a production deployment, the more scope there is for bugs to slip through. Testing of a deployed component makes getting code coverage metrics more difficult than in regular unit tests, but is still possible.

Frameworks such as the Jersey Test Framework can allow unit testing of JAX-RS REST endpoints that have been created, but this is not equivalent to a truly deployed component and so features such as CDI and the MicroProfile features I am looking into cannot easily be tested this way. While not related to MicroProfile, testing of DAO code is another area which has traditionally been an integration approach, as it required a running database server, but there are now libraries available that can allow this to be tested as unit tests.

» Continue reading

I have a Nexus 3 server running on my internal network which I was using for testing some performance related things, which were relying on the Payara Micro feature that enables it to deploy artifacts from Maven coordinates directly.

What I wanted to do was to have my local machine know where to publish build artifacts, but not have the details of this server published in the publicly available pom file as it is not relevant to anyone except myself. Usually the server URLs are stored in the distributionManagement section of the POM file.

» Continue reading