Summer travel choices:

• Hint as a base for Nawak.
• Nawak (editor / vm / platform).
• Conductor 2.
• Portnawak (quick game to learn kotlin).

Another idea to explore:

• Read a SCARM file and generate 3D track data for blender.
• Layout software for Android / mobile. Scrap existing library data to get started.

Maybe that’s what Portnawak could be: a potpourri of random mobile apps “1 day” experiments, with multiple absolutely unrelated activities in the same app.

Decided on the following plan for this summer:

• A 1-week addition to Portnawak as a simple “falling dot” game. Goal is to not focus too much on the engine part and develop some real kotlin code.
• A very very short throw-away track layout experiment. How would interaction work? Consider having only 2 pieces of tracks (1 straight + 1 curve) with auto-snapping. The goal here is to put that code in a generic library + UI that is android specific.
• After these 2, consider if I want to keep using kotlin or go back to Java.
• Then move on to the simulator for Conductor 2 (java app). Structure it at all in a library except UI in a java project (swing) or web rendering.

---

My main objection with the Wyze Cam is still the cloud-only and reports of outbound traffic.

Also “cell phone only, no web site”

So, way to work around this: https://openip.cam/ 

The base for the Wyze is the Xiaomi XiaoFang (see fang-hacks), which is not actually cheaper.

---

The next phase in Rig4 is to be able to generate a simple blog.

---

In Cab2 / RTAC, the mDNS discovery generally gives IPv6 addresses before IPv4.

2 things to investigate:

• Why the code always seems to fail to connect to the IPv6.
• Can I programmatically convert an IPv6 into an equivalent IPv4 (at least for local networks) and try that instead?

---

Things to look for:

• A per-page “share to FB”. https://developers.facebook.com/docs/sharing/web
• FB markup: https://developers.facebook.com/docs/sharing/webmasters#markup
• A per-page “share to G+”
• G+ markup?
• Twitter meta-data: https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/summary
• Microformats v2: http://microformats.org/wiki/microformats-2
• RSS feed for “blog” page?

From http://www.kevinmarks.com/partialsilos.html: G+ will parse the FB “open graph”.

It links to http://schema.org/Article which is Meh2.

I’m not sure I want “share buttons”. What I’d like however is being able to tag a snippet + target image with an izu-tag and then let it generate the sickening tags automatically.

---

Rig4:

• Got a whole new implementation in Java. Works using gdoc, local hash cache to avoid updating content that has not changed. Aggressively trims exported HTML. Not even using Material Design Lite nor Bootstrap, keeping it super simple.
• This is “good” enough for now. It is all an “exp” prototype and not per spec.
• Might implement the Rig4 spec for MM later?

Randall:

• Back in business. Work on laptop, work on tablet, work on turnout control.

Software:

• Cab Engineer (v2 for Cab Throttle). Next project in line.
• Monitor (on hold).
• Nerdkill Unity (on hold).

---

Rig4 was not generating drawings anymore.

Two issues:

• The generated URL for drawings changed from docs.google/com/drawings/image?id=... to docs.google.com/drawings/d/<id>/image?...
• The generator was not generating an error on unprocessed docs.google.com links. That means these were exposed in the generated HTML and savvy-enough users would try to follow them, get an access denied and ask for permission to get access to the underlying doc.

Although Rig4 experimental doc generating work, it's still an ugly hack. It's very dependent on the generated html format. In essence the system is too fragile and doesn't work.

Also it regenerates every time, regardless of whether the source has changed.

So eventually I need to fix that.

The Drive.files.export API has the following formats for download:

https://developers.google.com/drive/v2/web/manage-downloads 

• Docs export to HTML, text, rtf, Open Office, PDF, MS Word, EPub.
• Drawings export to JPEG, PNG, SVG, PDF.

The Python-based implementation is a core part of the issue, and it’s clunky.

As far as languages to use, although Go works in its own clunky way, I'd like to get away from it. I'd say the contenders are Java or Node.js at that point. The Drive API also offers .Net, Python, PHP and Ruby but I need to standardize on something and JS might do it for what it's worth.

---

• ESP8266 (wifi / mesh, e.g. library easyMesh)
• NRF24L01 (in the 2.4 GHz band)
• RFM69 (< 1 Ghz, from last thread here)

---

Current projects or ideas and their status, more or less from higher to lower priority:

• Randall: Setup the linux box to auto-start with JMRI faceless and my controller script.
• High priority, EOM / EOY.
• A sub-project is having a non-authenticated display on the laptop, which could be either in the form of a screen saver or a non-privileged user in auto-login running a single full screen app that can't be closed. Ideally: EOY. Useful for me.
• Randall: RTAC android app for tablet.
• High Priority MVP by EOM / EOY on at least one tablet. Can be fine tuned later.
• Home Monitor:
• Redo circuit board for alarm interface + box. Still want it. Low-priority because works well and kinda like the hackish look.
• Current RPi setup works well.
• Monitor android app using Firebase is meh ⇒ Rebuild without Firebase, direct App Engine web + Android w/ notifications.
• Cab Engineer:
• A v2 of Cab Throttle. Rewrite app using my RX instead of event bus.
• MVP should have server save/recall, engine save/recall, soft-consist, wear.

---

I should try to make my own little Rx clone lib.

There are a few good things in the RxJava lib but it also has these issues:

• It does too much for my needs.
• On paper, and when viewing a few first tutorials, it's all good. But then it breaks down. There's RxJava 1 vs 2. The vocabulary confuses me to no end. There's too much of an initial learning curve for what looks like a simple concept on the paper.
• Example of vocabulary confusion:
• An "observable" is actually a stream of events. Then call it a stream.
• "Observers" actually subscribe to a stream. Then call them subscribers.
• A source or an emitter is the same thing.
• A consumer is an observer (subscriber).
• Then RxJava 2 adds its own confusion by having Flowable vs Observable, and their version of the Observer is now called a Subscriber (as it should).
• RxStream uses even different names: Publisher, Subscriber, Subscription, Processor.
• The issue with this is the same as with languages like Ruby and Go: They are "almost" easy to get but yet different. When I move away from one for 6 months or a year, I need to go through the ropes again to get familiar with what I wrote a year ago. A "good" framework is something that is intuitive for me and I can just re-read my old code without wondering what it means or why I wrote it that way.

I'll use the RxStream terminology:

• A Publisher is the source, emitter, generator. It takes a stream and publishes new events onto it.
• A Subscriber is the reader, consumer, observer. It takes a stream and reads from it.
• Schedulers (from RxJava) express which thread a publisher or subscriber runs onto.
• A Stream is a pipe that sends events from the publisher(s) to the subscriber(s). It can be a 1-1 or a N-N combination.
• Streams can be created empty and publishers and subscribers added to them in any order.
• Streams are either open, pause or closed (aka "completed").
• Closing is final. Once closed, publishing generates an error.
• Subscribers can pause the stream, which blocks subscribers.
• Processors are stream filters/maps. They take one or more streams and combine events  together into a new output stream.
• Example: map(lambda X ⇒ Y), take(N), delay(N), merge().
• Subscribers are notified when publishers are added or removed.
• Subscribers are notified when publishers pause the stream.
• Publishers are notified when subscribers are added or removed.
• Streams are by default asynchronous and multithreaded.
• When there are multiple publishers or subscribers, they could all be on different schedulers.

Canonical examples:

        S = Stream.create()  # can be exported via dagger

Or

        @Inject Stream S;

        S.pause(true);

        S.addSubscriber( … ).on( Scheduler );

        S.addPublisher( … ).on( Scheduler );

        S.addProcessor( map( … ) ).on( Scheduler );

        S.pause(false);

        S.isPaused();

        S.close();

Async task:

        Stream.on( Scheduler.io() )                # sets default scheduler unless overridden

                .publish( fixed data, e.g. some url )

                .publishOn( Schedulers.io() )  # affects the last added publisher

                .map( lambda worker: url ⇒ http request ⇒ body response )

                .processOn( Schedulers.io() )  # affects the last added processor

                .subscribe( subscriber lambda )

                .subscribeOn( Schedulers.androidMainThread() ); # affects last subscriber

[Update 2017-08-20]

Once this is implemented, I have one issue: should users be able to publish directly on the stream, or always via subscribers?

Example:

        _pub = MyCustomPublisher()

        _stream = Stream.on(Schedulers.io())

                .publishWith( _pub )

                .subscribe( SomeSubscriber() );

        _pub.publish(42);

        _stream.publish(43);

Now we have 2 ways to inject events in the stream: via the publisher and via the stream directly.

The latter overrides whatever behavior from the publisher: we might have used a Just() publisher that only provides its constructor arguments yet we can still add more.

In essence, the publisher does not control whether the stream is "read-only".

So a different strategy is:

• Only Publishers can publish on a stream.
• Users that hold a stream can't publish directly.

Furthermore, we're reducing the scope of each objects:

• Stream methods only serve to configure the stream itself.
• Publishers decide if they expose a public publish method.
• When they don't, they become closed generators.

---