Over here on the servers, I know have a script that monitors the Raspberry Pi (1 or 4) temperature and prints it when it rises:

#!/bin/bash

CA=0

CI=90000

while true; do

  C=$(</sys/class/thermal/thermal_zone0/temp)

  if [[ "$C" -gt "$CA" ]]; then CA="$C"; fi

  if [[ "$C" -lt "$CI" ]]; then CI="$C"; fi

  D=$(date)

  T=$(python3 -c "print('min: %f C | curr: %f C | max: %f C' % ($CI/1000., $C/1000., $CA/1000.))")

  echo "$D : $T"

  sleep 5s

done

Note this is not a service, just a basic shell/python script to run ad-hoc.

The RPi 4 is currently around ~50 C, with no fan.

According to sources, it can go up to 80-85 C before it starts throttling to reduce heat.

So first, let’s make this clear: DWM is both terribly good, and terribly bad.

• Excellent small footprint and minimal functionality.
• Keyboard only usage is both excellent yet terrible. I generally don’t remember the shortcuts except for the 3 main ones: Alt-S (new shell), Alt-1..9 to select a workspace, and Shift-Alt-1...9 to move a window to a workspace (they call them “tags”).
• A lot of programs aren’t designed for the “full screen / forced tiling” approach and require some kind of floating windows to be usable.
• DWM has basically one “window model”: a main shell, and a stack of secondary windows opening on the right of it. It’s really designed to have one shell per workspace.

My window manager of choice is LXDE. It’s very light in resources, and in features, yet it’s a “proper” window manager. I could do without the session manager aspect.

As a thought exercise, how would I use Consist with DWM?

• I have 3 shells that start. Ideally they could be tiled on space 1.
• JMRI needs 3 windows: JMRI main, WiThrottle, and Conductor.
• JMRI main + WiThrottles could be tiled on space 2.
• Conductor should be tiled on its own space. Is that possible, or does it need to be with the rest of the app?
• When debugging, I like to have Conductor + the JMRI shell window together.
• When resetting a failed automation, I like to have Conductor + 1 or 2 new JMRI Throttle windows together.

That’s the part where DWM starts to suck. It’s not designed for this kind of functionality.

On the GA4 front, I now have some basic dashboards working for Randall:

• Alfray blog                        DONE
• GGMRC                                DONE
• Conductor 2                        DONE
• Server Pings                DONE
• Inkblot3 (flutter)        Already GA4
• RTAC (tablet)                TBD
• Vision                        DONE
• Other web pages?                TBD

On the Rig4 front:

• Rig4k is slowly starting.
• Have some good skeleton around.
• Gdoc separation/caching is not as clean as desired.
• Starting to focus on the html-to-izu.
• Rig4j:
• Found a way to re-inject the missing CSS styles, so this temporarily fixes the web site's lack of bold / italics / tables.
• So basically one more little bandaid keeps this working for now.

Something to try:

• Aida/Web: https://www.aidaweb.si/tutorial
• Seaside: https://www.seaside.st/documentation/tutorials
• Book: https://book.seaside.st/book 
• Pharo-by-example is a hijacked web site, just ignore it.

The critical question is why bother? Flutter / React already offer well-rounded frameworks, and Smalltalk is just yet-another-esoteric language. It’s on the same level as JS/TS/Dart when it comes to “stuff I only use occasionally”, with the typical issue of feeling mostly write-only.

On that part, I ended up actually enjoying Dart as it seemed like a suitable compromise between Java, JS, and TS.

Flutter vs ReactJS:

• Pro of Flutter = dev in IJ… The integration is excellent.
• Cons of Flutter = dev in IJ… Requires IJ to edit a project.
• Same goes for ReactJS. The VS Code integration is good, but lacks an IJ-level project management.
• VS Code is good for short-sided projects (e.g. Wazz), whereas IJ is better for large project organization.

The Looker+GA4 behavior is currently limiting. It also exposes the typical issue when relying on external “free” services. Are there ways I can bring my stats in-house?

2 aspects come to mind:

• Sending the event data…
• With the usual caveat of outage reliability, the data would be better hosted on my own server.
• An option would be to use MQTT to transport that data around.
• Viewing the data…
• Can I write my own Looker connector pulling data from my server?
• Are there other MQTT-based or similar web-based stats pages I can reuse?

I’m not particularly interested in writing my own graphs, even though I’ve certainly done that.

There are Linux packages that can pre-render graphs and I can expose them via ssl.

Can MQTT be used as either a transport mechanism, storage, or a data source?

What: https://bitbucket.org/blog/ssh-host-key-changes

Verify by running this command on each host:

$ ssh git@bitbucket.org host_key_info

> You are using host key with fingerprint:

> ssh-ed25519 SHA256:ybgmFkzwOSotHTHLJgHO0QN8L0xErw6vd0VhFA9m3SM

> ecdsa-sha2-nistp256 SHA256:FC73VB6C4OQLSCrjEayhMp9UMxS97caD/Yyi2bhW/J0

ECDA or ED25519 are GOOD.

Got “Permission denied”?

https://confluence.atlassian.com/bbkb/permission-denied-publickey-302811860.html

⇒ This should happen for any machine where I did not load an SSH Key in my Bitbucket account.

⇒ If I have an ssh-agent key, load it first.

⇒ If I don’t expect to have ssh auth, then it’s fine. In this case, grep bitbucket ~/.ssh/known_hosts ⇒ vim ~/.ssh/known_hosts and remove any reference to bitbucket).

To accept the new host on a machine that needs git access:

$ ssh-keygen -R bitbucket.org && curl https://bitbucket.org/site/ssh >> ~/.ssh/known_hosts

then rerun the host_key_info cmd, access the key with “yes”, and repeat again to remove any duplicated host entry.

No choice, GA is giving me more and more warnings about the incoming GA4 migration.

Tasks:

• Build an exhaustive list of projects actually exporting to GA4.
• Find how to send GA4 events from my bash scripts.

Taking a reverse approach to that, the Stats Pages I look daily are:

• The Randall Camera Access stats. Data comes from wazz.js.
• ⇒ This seems like a good contender to learn the “official” JS API.
• The Train Activation stats generated by Conductor.
• This uses ad-hoc URL pings.
• And also uses bash-based wget pings.
• The Servers Ping stats.  This uses bash-based wget pings.
• ⇒ This seems like the best candidate to look for a wget alternative.
• The Inkblot Access stats. This uses the official Flutter library.

Migration guide: https://support.google.com/analytics/answer/10759417

• Universal Analytics (UA) is the old one.
• Setup Assistant: https://support.google.com/analytics/answer/9744165
• Account Structure: https://support.google.com/analytics/answer/9679158
• UA structure: Account ⇒ N * Properties (e.g. website) ⇒ M * Views.
• The Property number starts with UA-
• GA4 Structure: Account ⇒ N * Properties (e.g. website) ⇒ Data Streams.
• The property number is a long number.
• Looks like GA4 numbers have already been created for each one.
• Events are changing: https://support.google.com/analytics/answer/11091422
• UA events have events category > event action > event label.
• GA4 events are firebase events: event name + event parameters.
• UA event action becomes the new GA4 event name
• UA event category becomes a GA4 event custom parameter
• UA event label becomes a GA4 event custom parameter

Back there on the RIG 4 Spec [Idea] project page, I have a different angle for a rewrite of Rig4.

The summary is that the current version of Rig4j is still running the “early experiment”. Code base was mostly “feasibility”. When exploring the Rust-based Rig4r, I realized it would be better structured by separating the gdoc functionality from the “rig” generator functionality: one tool does the gdoc fetching, and then Rig works on purely local files.

The new angle is that the gdoc fetching should actually generate izu files, by parsing the gdoc html exports and rewriting them as izu/markdown text files. There would be some limitations on the format. Not all the formatting would make it through.

This would also involve looking at the format I use in the train blog, making an exhaustive list of features used, and try to match some level of parity. Luckily I don’t use too much stuff, but tables seem like they could be tricky, and I’d also want to support the linkable TOCs and their existing hrefs. Some things like usage of titles in article pages did not exist in izu.

I may also want to consider dropping my izu format, and focus on “official” markdown.

I can probably fairly simply translate old izu pages to markdown if such support is needed.

OTOH it would solve one of the current problems, namely that the page format is dictated by the gdoc html export, and that has been known to change substantially over the time.

The end goal is to not have such a strong dependence on gdoc. That makes gdoc merely a convenience to more easily write the izu files, and then the izu files become the “source of truth” that I need to backup.

This is new:

java.lang.RuntimeException: com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 Forbidden

{

  "code" : 403,

  "errors" : [ {

    "domain" : "global",

    "message" : "This file is too large to be exported.",

    "reason" : "exportSizeLimitExceeded"

  } ],

  "message" : "This file is too large to be exported."

}

        at com.alflabs.rig4.gdoc.GDocHelper.lambda$getGDocAsync$0(GDocHelper.java:491)

        at com.alflabs.rig4.struct.GDocEntity.getContent(GDocEntity.java:54)

        at com.alflabs.rig4.blog.BlogGenerator.parseSource(BlogGenerator.java:135)

        at com.alflabs.rig4.blog.BlogGenerator.parseSources(BlogGenerator.java:120)

        at com.alflabs.rig4.blog.BlogGenerator.processEntries(BlogGenerator.java:69)

        at com.alflabs.rig4.exp.Exp.start(Exp.java:60)

        at com.alflabs.rig4.EntryPoint.main(EntryPoint.java:53)

As usual, that makes me reconsider my dependency on the GDrive API.

Here’s the end result of the Fuse to perform image removal on my train videos:

https://bitbucket.org/alf-labs/lightworks/src/master/fusion/fuses/RalfCamCarRodRemoval.fuse

and here’s an example of the result:

https://www.alfray.com/trains/blog/train/2023-06-04_davinci_resolve_plugin_for_t_4126bb12.html