Building a plotter (part 3)

There is a problem I have been hinting at from part 1.

FluidNC does not support the touch screen on the Makerbase MKS DLC32.

There are good reasons for this. You are entitled to disagree with the reasons, but they are valid.

The number one issue is that not all of the hardware that FluidNC wants to support are powerful enough to drive a display let alone drive one that has touch.

Building a plotter (part 2)

So the Makerbase MKS DLC32 arrived. My challenge was how to mount it onto the frame and keep all the wires hidden.

Normally I would fire up OpenSCAD and get my calipers out and risk the wrath of my family while I disappear for 3 days designing the enclosure to print.

This time I said, let’s see what the LLMs can do.

Building a plotter (part 1)

About two years ago I finally pulled the trigger and purchased a 3D printer. Now I missed the Great Fun™ part of the 3D printing hobby where you spent more time hardware hacking than actually printing. My 3D printer just works. It’s a utility. Sure I got to upgrade it from a bed slinger to a core-XY, but there was never any doubt that it would work at the end of the upgrade.

When a Kubernetes Operator Makes Sense

Beyond YAML: Real-World Lessons from Managing Complex Infrastructure

There are plenty of ways to deploy applications onto Kubernetes:

• raw kubectl apply
• Kustomize overlays
• Helm charts
• sidecars and init containers
• and, at the far end of the spectrum, fully-fledged operators

Most teams start at the simple end and stay there. And they should, most applications don’t need anything more complicated than a Deployment, a few ConfigMaps, and a kubectl apply -k.

About 19 years ago, I set up a blog on Google’s Blogger platform to track my adventures learning Java: https://javaadventure.blogspot.com/

The platform has changed a lot since then, and not always for the better. Many posts no longer render the way they used to, and a few images have disappeared entirely.

One feature I really loved, which is now broken, was the ability to email a special address and have the message automatically turned into a post. It made publishing effortless… though that was also before I discovered what was then X (née Twitter).

Another interesting tidbit:

@Benchmark
public void debug1Arg_date(Blackhole blackhole) {
    LOGGER.debug("Started at %s", new Date(time));
    time++;
    blackhole.consume(time);
}

@Benchmark
public void guardedDebug1Arg_date(Blackhole blackhole) {
    if (LOGGER.isDebugEnabled()) {
        LOGGER.debug("Started at %s", new Date(time));
    }
    time++;
    blackhole.consume(time);
}

Gives the following benchmark results:

Benchmark                            Mode  Cnt          Score         Error  Units
Log4jBenchmark.debug1Arg_date         thrpt   20  179653191.248 ± 2731044.349  ops/s
Log4jBenchmark.guardedDebug1Arg_date  thrpt   20  207001790.376 ± 2074020.617  ops/s

We can also compare guarding with SLF4J over logback

One of my colleagues had a question:

Now for some context, when the Jenkins project started off, Kohsuke was working for Sun and felt it would be wrong, as a Sun employee, to use a logging framework other than that provided by the JVM as using a different logging framework could be seen as being implication that the built in Java Utils Logging framework was a steaming pile of excrement.

You asked for it.

Logback:

@Benchmark
public void debug1Arg_date(Blackhole blackhole) {
    LOGGER.debug("Started at {}", new Date(time));
    time++;
    blackhole.consume(time);
}
@Benchmark
public void debug2Arg_date(Blackhole blackhole) {

    LOGGER.debug("Started at {}", new Date(time), null);
    time++;
    blackhole.consume(time);
}
@Benchmark
public void debugNArg_date(Blackhole blackhole) {
    LOGGER.debug("Started at {}", new Date(time), null, null);
    time++;
    blackhole.consume(time);
}
static {

    ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger)LoggerFactory.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
    root.setLevel(ch.qos.logback.classic.Level.INFO);
}

And the benchmarks

Benchmark                     Mode  Cnt          Score         Error  Units 
LogbackBenchmark.debug1Arg_date  thrpt   20  221056534.656 ± 8549233.826  ops/s
LogbackBenchmark.debug2Arg_date  thrpt   20  220576341.742 ± 3778270.898  ops/s
LogbackBenchmark.debugNArg_date  thrpt   20  134887126.088 ± 2973182.812  ops/s

JUL over SLF4J (same benchmark code but different dependency)

If there are two only things guaranteed to cause all out war between developers, my vote is that those two things are:

• Code formatting conventions

• Version number conventions

The first is resolved trivially (just shoot anyone suggesting the use of TABs). Until recently most people thought the second was resolved by semver… at least until the developer of one of the more commonly used JavaScript libraries threw the cat amongst the pigeons.

One of the headline grabbing things that people seem to be raving about over Log4J 2.0 is async loggers.

Now do not get me wrong, they are great… as long as you know what you are doing.

If you are using async loggers you had better make sure you are only passing immutable objects to your loggers, because otherwise you may end up logging the state of your objects at the time of the log record being written and not the time you called log.