Rig4j has some unit tests. As with other unit tests, I’m always dubious of their quality, coverage, or usefulness. Writing these tests takes a lot of time, and maintaining them is a PITA.

However, I did a change in Rig3. I was glad to see this old project had some tests. Lots of verbose warnings when running them, but at least they gave me a baseline for the one change I had to make… it showed me how my own code was running, since I had largely forgotten. And I was able to break the tests as expected with my change, then adjust the tests. Thus they served their role in a TDD scenario.

Now I’m looking at Inkblot2 and I skipped the testing part for all the React code. After all it’s just presentation, right? I have only a couple unit test methods for computational functions.

A decade ago, I wrote a little backend for Timeriffic to enable themes per user. It’s just a simple REST API served by a Go app-engine with a CRUD admin frontend. And it’s written in Go 1.1 (IIRC), and now I need to update to Go 1.9. I seriously hope I wrote some tests, and here’s what I expect of these tests:

• First run them ideally with a Go 1.1 runtime (assuming I still have that), and validate they work.
• Next run them with a Go 1.9 runtime, and if the app builds, see which part of the test works or breaks. In essence, I just want a baseline of what’s broken by the change.

Which parts do I expect to be covered?

• On the backend REST API side, a get without a valid auth, and a get with a valid auth. That last one should also cover reading from a mock db.
• On the admin frontend, render the page without login, with login, and validate a simple CRUD usage (create an entry, see it listed, remote it, see it gone).

These tests are not designed to do 100% coverage, yet they should cover the basic usage scenarios. Even if a full CRUD cycle is not exercised, the viewing part should be tested, e.g. login and display an empty list, login and display a list with known data.

I want to emphasize this is not the TDD philosophy here. We’re not using tests to validate every single inch of the app, every single little possible case. At the contrary, the tests should cover large strokes, making sure the obvious is not broken.

Thus Inkblot2 really needs something like that.

I do remember that my little dabbing in Go did not show great ways to mock whole components such as database or logging auth. That’s one of the reasons I went back to liking Java all because of Dagger and how it enables that trivially, all at compile time. I’m curious what React JS has to offer in that regard.

In my perpetual reshuffling of home projects, I need to bump up rig4j, and abandon rig4r.

Rig4r: It was somewhat useful to learn Rust lang. However I really don’t care much about it. That language does not solve any problem that I don’t really have.

That said, it wasn’t a complete loss. The rig4r project showed me there’s some value in splitting rig4 in a gdoc-downloader vs a generator.

In the current train site+blog, a simple blog update results in a 6-7 minutes rig4j run time.

90% of that time is in checking images/graphics have not changed -- it takes about forever to pull them off gdoc using the current gdoc API… this will get addressed whenever I focus on rig4j again and implement the caching I specified from the start yet never fully implemented yet.

It’s also worth noting that the current rig4j is really “0.1-exp”.  There would be some value in taking the learnings from that experiment -- what worked well, what did not work --, cross-reference that with the initial spec, and maybe re-implement from there.

The main pain point is looking up all these gdoc images instead of relying on cached blobs.

The second pain point is the HTML exported by gdoc. I have it somewhat cleaned up, yet I think even more could be done. On one hand I’d like to strip it down as much as I can to the level of what is/was supported by izumi’s syntax, and on the other hand I’d like to retain some complex elements such as tables.

The latest Debian Busty offers Java 11 via OpenJDK. There’s also a comment on the OpenJDK web site that from now on all official Java releases are done via the OpenJDK (site/framework)... does that mean one no longer has to wonder about Java vs OpenJDK compatibility? That would be nice.

Of note: Debian has an openjdk-11-headless… no more need to drag X libs pointlessly.

It also begs the question of “what’s new in Java 11”... and what can be used on Android.

https://simply-how.com/getting-started-with-java-11

• Java 9:
• A new concept of “modules”, a “self describing collection of code and data”.
• Jlink, a tool with a link time phase vs compile time phase, using modules.
• Jshell, a REPL … that can come in handy.
• Multi-release JAR files: version-specific of classes in the same JAR.
• Private methods on interfaces, which can be used by default methods.
• Rx compliant Flow API.
• Factory/collections methods: Set.of, List.of…
• Stuff I don’t care, e.g. garbage collector changed. (skipping those below).
• Java 10:
• “Var” keyword for local type inference.
• Optional.orElseThrow.
• Unmodifiable collections: List.copyOf, etc.
• Java 11:
• HTTP Client API (do I care?)
• “Singe-file source-code programs”... sounds like scripting to me.
• “Var” keyword can be used in lambda parameters.
• Java 12:
• More garbage collector whatever this or that.
• Mostly nothing except some *preview* of a condensed switch/case/break syntax (e.g. the “break” also acts as a “return”, and can be further condensed to an -> arrow syntax)... meh.

Bottom line: mostly nothing to see here.

So overall a fairly incremental update to the language. The most notable useful thing is the “var” keyword. Since it is type-inference, I expect it can generate backward-compatible bytecode running fine with older JREs. New APIs like collections would obviously require the latest JRE to run.

We still don’t have support for “safe-dereference” (?. which was proposed for Java 7!) and folks horrendously suggest using Optional instead.

For gradle, the usual:

targetCompatibility = 11

sourceCompatibility = 11

Or

compileOptions {

    targetCompatibility JavaVersion.VERSION_12

    sourceCompatibility JavaVersion.VERSION_12

}

Thus it seems to me overall I’d want something along the lines of “target 8… source 11”.

Currently working on Inkblot v2 Scoring Web App.

The suggestion was to evaluate AWS vs Firebase (nodejs based, not Android as I usually do).

AWS is working really well work Inkblot v2 right now, so there’s little incentive to also do a Firebase version.

I’d still like to do a web app using Firebase to have a comparison with AWS, and Seeds seems like a good candidate for this. I have the Android app working fine, however my old Chrome extension does not work anymore since the AppScript-based apps have been deprecated.

Rebuilding it using Firebase would be a good target:

• Rely on their free tier, and measure cold latency (one of the big drawbacks of app engine in their free tier, which I do not see in AWS).
• Nodejs + React + Bootstrap, similar to what’s used in Inkblot v2.
• Google-only auth… how well do they integrate that in Firebase?
• Backend storage… how does it compare with GraphQL + DynamoDB?
• Note: the only thing I really need is to store the GDrive doc id.
• Deployment/hosting… this one would likely go on something like “seeds.alfray.com”.

Updated 2020-09-24: That project could also be a candidate to look again at Angular. I remember looking at Angular before React and couldn’t figure out the model… However now that I’m familiar with React (non native), looking at Angular a second time would be worth it, for a good comparison.

Current projects, either actually ongoing or started/pending:

• Conductor 2, the rewrite using a Groovy DSL. Want to continue. Perpetual hold.
• Low interest as the current version is “working fine” (with its limitations).
• I would have some renewed interest combined with home usage.
• Timeriffic 3…
• 2019 attempt did not work, it crippled most of the functionality, the impl was borked, it didn’t even really work well for basic stuff.
• That needs a full reboot if it’s going to go anywhere.
• This could be a candidate to do an app using RxJava + Kotlin.
• Jump Godot game.
• This is mostly a “technology” demo for Godot 3d to understand limitations.
• Got initial MVP (without the IAB part) on Play.
• There is no interest in making it a full blown complex play.
• I should take the MVP down, e.g. keep it alpha instead of public.
• Asqare.
• A reboot using Godot 2d.
• Sudoku
• May have some limited interest if it were to be a Kotlin + RxJava test bed.
• Risks having the usual issue of not going past the MVP.
• Dcc Cab:
• Current version is on Play. Not advertised much. Does what I need from it.
• Rig4r:
• Limited interest in Rust itself, however I can see how it is appropriate here.
• May continue… slowly?
• ESP32 vision.
• The 2 initial targets for this are crossing signal and virtual block detection.

Starting one and exploring a tech is easy and fun. Jump/Godot is an example where I had fun starting it. It fell a bit flat once I had the premise of a working version. I lack a push to complete these, and once the novelty wears off, there’s little incentive to continue adding to it instead of focusing on another idea.

For Rig4r, the initial objective was to spend a long week-end learning what Rust is all about. I’ve done that. I have no specific love for the new language, but neither did I for any other new language I’ve tried recently (Haskell, Go, Kotlin,... and now Rust). That’s because these languages do not fill any need that I don’t really have -- they really do not do anything Java can’t already do, no matter what the fanboys say. For example I’m not really happy with the current implementation of Rig4j, and that’s really not a Java/Dagger issue at all.

No amount of language hype is going to magically fix an implementation.

The other realization I made with Rig4j, the Java version, is that external libraries are what matters. In this case, the availability of a G Drive API and the HTML jsoup parsers were keys.

Would a rig4 reboot be a good target for Rust?

Rust and Google drive api: https://docs.rs/google-drive3/1.0.14+20200618/google_drive3/

Rust and html soup parsing: https://docs.rs/scraper/0.12.0/scraper/ and some more references.

A real reboot needs to focus on 2 different issues:

• The GDrive api to fetch docs is slow as molasses. It would make sense to separate this process, e.g. download and cache locally. The obvious issue is that fetching a doc requires parsing it to find its dependencies.
• More robust sanitizing of that drive html into rig 3 syntax.
• The tree parser and generator.

The focus here should be on caching to avoid fetching from drive as much as possible.

The other focus is on parsing that html and stripping it even more than I do now.

There could be 2 tools:

• Rig4 docs downloader that takes drive docs, the index, the blogs, and generates local rig4 files, updating assets when needed.
• Rig4 generator that only works locally.

Currently Asqare is totally off Google Play due to an injection vulnerability in the SQL code handling the score saves. The issue is rather irrelevant, but the automated Play tools don’t care and backlisted the app years ago.

Rebuilding it is possible… One reasoning a while ago was to do a reboot.

Today if I had to do Asqare again, I’d do it in Godot.

When a “custom Android build” gets created from the Godot android export, the generated GodotApp contains references to a GodotLib, which is provided as an AAR in the project.

A quick look at it in Studio shows references to a lot of stuff like event management, but also Payments classes, etc.

So let’s look at what Godot has that is linked to Android:

https://docs.godotengine.org/en/stable/tutorials/plugins/android/android_plugin.html: A “Godot Android plugin” is an independent AAR that one can add to a Godot project, and then use from the GDScript.

For example there’s a plugin for Oculus VR, and an official one for Google Play Billing compatible starting with Godot 3.2.2.

GodotPaymentsV3 is an older library that is superseded by the above Play billing plugin.

Now it's time to take [...] and understand Godot with 3d.  

Link to blender 2 godot exporter:

• https://gamefromscratch.com/blender2godot-add-on-released/
• Points to https://www.zammedev.com/home/wip_projects/blender2godot
• Points to https://gitlab.com/Zamme/blender2godot

This seems like a good way to get started. Create something in Blender and convert it to Godot.

One obvious teaching from some games is that a 3D game can basically be just a 2d game with a 3d rendering. That is probably the easiest way to get started.

Here’s an interesting topic to look into: Rust language, which presents itself as a Go / C++ alternative. But more importantly, how would it far in the content of:

• ESP32 or Arduin dev
• Integration with current libraries for Arduino.
• Integration with “generic” libraries such as OpenCV.

There’s something here for ESP32: https://github.com/MabezDev/xtensa-rust-quickstart

Several comments indicate that the rustc compiler can target ARM CPUs; and while not stated I’m guessing that would exclude all the AT-based Arduinos.

OpenCV bindings for Rust: https://docs.rs/opencv/0.45.0/opencv/

So that seems like it is a choice.

Apparently Rust stuff is packaged in “crates” and using a tool named “cargo”.

This reddit post indicates that “The only complete binding to the C++ API is opencv-rust, not to be confused with rust-opencv and rust-opencv-sys, which bind the C API.”

Here’s a random post on doing a React-like single page web application. One keyword I see often is “documentation is sparse”. One thing a lot of people misunderstand with new languages is that doxygen-style or javadoc-style API documentation is not a developer usage guide.

Apart from that, code examples seem fairly Go-like in spirit.

(Future self comment: I’ve made 2 attempts at jumping on the Rust hype bandwagon so far, one for server and one for ESP32, and these efforts didn’t go anywhere. I wasn’t exactly impressed.)