The last weeks, I’ve been overwhelmed by work, so no time to work on the blog or write posts. Also a bit depressed by the state of the world. And some family troubles that need time and attention.
Here’s to a positive outcome for all of this.
The last weeks, I’ve been overwhelmed by work, so no time to work on the blog or write posts. Also a bit depressed by the state of the world. And some family troubles that need time and attention.
Here’s to a positive outcome for all of this.

This post is about the product we are building at Toolsquare.io
The recent/ongoing DDoS1 in the Netherlands impacted our customers, and our own product.
Although we don’t have publicly accessible endpoints on the customers network, we dó have to use their network connection to connect our hardware with our cloud platform. As an IOT solution, this is obvious. We do not supply our own WiFi network or cellular network, in order to reduce costs.
When creating an IoT productivity system, the last thing you want is to get in the way of your user’s productivity. That’s why we implemented an offline mode on our hardware that allows the user to continue to work in case there is no network connectivity. This feature can be enabled on a per-device basis.
As a consequence of the ongoing DDoS attack, network traffic is slow. This leads to long connection times, and response (failure to connect or connection success) takes more time to come in. Some of our hardware units were failing to go into offline mode because of this, and stuck in a reboot loop. Once we figured this out, a fix was quickly deployed and our customers can continue their work in offline mode.
We have a robust test plan with unit tests, integration tests and end to end tests that takes many things that can be simulated into account. After today’s experience we will add slow network testing for our hardware/firmware to this by building a Raspberry Pi network emulation device that can simulate slow network behaviour.

Upgraded the old Fujifilm with a new strap
With WooCommerce 9.4, WooCommerce Brands is getting rolled out to a cohort (5%) of installs.
If you do not want to participate in this change set the option woocommerce_remote_variant_assignment to a higher value, e.g. 111
<?php
/**
* Ensures that the Brands feature is released initially only to 5% of users.
*
* @return bool
*/
public static function is_enabled() {
$assignment = get_option( 'woocommerce_remote_variant_assignment', false );
if ( false === $assignment ) {
return false;
}
return ( $assignment <= 6 ); // Considering 5% of the 0-120 range.
}While this is a good feature, it can break your existing brands solution as it did in my case on an existing ecommerce setup.
As a solution, set the new brands permalink to something different from brand, e.g. brands.