Interesting: Material Design Lite. https://getmdl.io/

Application could be interesting on the Trains pages. Find a way to inject in the gdoc-generated pages. [done]

Looking at the firebase tutorials for web / android…

Web:

• Uses nodes.js / npm for local testing + deployment.
• Google Cloud Whatever project with console for management.
• Firebase console seems to mostly cover deployment & database/files for web, not messaging or analytics. GA can be added separately anyway.
• Pros: authentication with a variety of platforms (G, Tw, FB, email).
• Overall interesting.

Android:

• Seems more refined with a variety of services: database, email app invite, GCM notifications, remote config values, analytics / crash reporting. And of course multiple auth providers. Also as admob support.
• Seems like a good value: reduce boilerplate for a bunch of things (auth, crash, ga, db, remote config.)
• Nothing about IAB, to be done separately.

From the Firebase tutorial, a good javascript ide is https://atom.io

• open source, free, runs js.
• using http://electron.atom.io to build "cross platforms apps using html+js"

Javascript not-quite-replacements:

• CoffeeScript: http://coffeescript.org … compiles 1-to-1 to vanilla JS.
• TypeScript: https://www.typescriptlang.org … also a compiler. More JS like, with decoration for types and access.
• - ES6: ...
• The high level summary is that CoffeeScript is Ruby/Python like and TypeScript is .Net like in their sugar-syntax addition/replacement.
• TypeScript seems to have a VS.Net add-on (confirm?)
• In terms of age: CoffeeScript < TypeScript < ES6.

Point of view: CoffeeScript is different enough that it's a new habit to learn. TypeScript is JS plus some sugar so can be used to decorate existing JS stuff. ES6 is the way to go but what about support? Compatibility chart here: ES6 supported in V8 since Chrome 42 (so also in Node.js). Mostly there in recent Firefox and MS Edge.

Bottom line: don't bother with CS/TS. Go with ES6 where possible.

One more thing to give a try: Firebase.  firebase.google.com.
What does it do, or doesn't? Why would I care?

It's apparently based on top of the google cloud platform. Key features include analytics, database, storage, hosting, authentication, and cloud messaging.

Idea would be to use the central monitoring and the AP projects to test it.

• Authentication: SDK has drop-in UI for auth, with several providers (G, FB, Twitter, email).
• "Realtime Database" is actually connected clients with a network-synchronized offline-persistent db. This is similar to one of my homebrew projects (except it's already done.)
• "Remote Config" seems very similar, but with values that can be fetched yet not activated.
• "Storage" is to be able to upload user-generated content. Files are accessible via the Google Cloud Platform SDK too e.g. for server-side operations.
• "Notifications" seems to be all about manually sending messages to users.

⇒ Try the web tutorial.

https://www.polymer-project.org/0.5/
Version 0.5 with core-scaffold (generic web site template), core-toolbar.

https://www.polymer-project.org/1.0/ 
With material design elements.

"Look at https://github.com/PolymerElements/app-layout-templates for a few simple scaffolds.

You should be able to copy one of those templates to replace core-scaffold in your application.

If you want a more comprehensive starting point for an app, you can also look at https://github.com/PolymerElements/polymer-starter-kit"

Example in use: http://google.github.io/dagger/ 
Code behind it: https://github.com/google/dagger/tree/gh-pages 

Also interesting: Material Design Lite. https://getmdl.io/ 

What should the next "new" project be?

Would be nice to have something with a server side component in Go and an Android part..

• A Go-based AppEngine server.
• Use Google/Android user authentication.
• A client/server MVP model (as much logic server side as possible.)
• Lua scripting for the gameplay.
• Short-range NFC exchange.

Note about JS stacks:

• Angular -- v1 vs v2
• ReactJS -- the cool new thing?
• this comparison and this one for a comparison with pros and cons. Seems to indicate to go with ReactJS.
• My take: looking at the source code being their respective home pages, the Angular one is impossible to read, the ReactJS is simple and natural. Go with the latter.

So there's the usual MVP -- Model / View / Presenter pattern, exploded in a distributed fashion. A server sends data, and the client has a bunch of presenters for that data. That makes the client somewhat "generic" in the sense that it just presents whatever data it is given.

MVP : model → presenter → view.

The view is "dumb" and only displays stuff. It's a ViewHolder essentially.

Model has all the data and no logic.

All the logic is in the presenter. The presenter is notified of view changes and updates the model and the views.

For a distributed server-client system, we want all the logic server side.

So really what we have is:

        Server model → server presenter (logic) → client proto → view renderer.

where proto is naturally a Cap'n Proto for example.

The difference between MVP and MVC: in MVC, the model has part of the logic (it dictates what gets sent to the View) and the Controller accepts the input and updates the model. In MVP, the view and the model are dumb, and the presenter embeds both the logic to go from M-to-V and the logic from the Controller (to go from V to M.)

Thinking ahead in terms of a game. Interaction cannot only be handled server side. Otherwise it would mean every user action would have a huge network delay impact. That prevents offline usage at best, and of course implies lag, at worse.

That means part of the model/presenter needs to be on the client:

        [Server + Client model] → server presenter → | → [Client model] → [presenter] → View.

The client presenter handles the immediate interaction and at the same time pushes back some updates to the server.

For offline play, that's all we need. For live server-backed play, that has 2 frequent issues:

Server needs to sanitize / validate inputs from the client. They cannot be trusted. Otherwise it encourages cheating by simple MITM techniques.

Server pushes updates to client regularly which are more trusted than local updates. That can create magical warping when there's a lag.

https://capnproto.org/ 

This seems like it could be a good match for Nodes and potentially other projects.
One obvious goal is cross-platform serialization without having to reinvent it myself.

For Nodes it could be used at the inter-nodes layer, to structure packets between nodes.
Nodes server should not care about their payload, with the exception that ideally as a service nodes should provide both a byte stream and a packet/message oriented stream.

There's a desire to reboot the Nodes project, but in fact that desire is somewhat unfounded.

Windows enumerate USB devices -- list usb: USBView

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff560019(v=vs.85).aspx 
• https://dev.windows.com/en-us/downloads/sdk-archive 
• and install only the "debugging tools for Windows".

Install path is
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\usbview.exe

There's also an x64 one but it's still under Program Files x86:
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\usbview.exe

Note on DigiX:
https://digistump.com/wiki/digix/tutorials/programming
Bootloader is SAM-BA with VID/PID 03EB/6124
Native USB mode is VID/PID 2341/003E

However DigiX appears with VID 0x16D0 and PID 0x078A

From http://digistump.com/board/index.php?topic=1185.20
VID : PID
03EB:6124   Atmel: SAM-BA activated device
2341:003E   Arduino DUE native PORT selected, sketch is running
16d0:078a   DigiX board selected, sketch is running

Now open Device Manager > Ports (COM & LPT).

It shows "Digistump DigiX (COM6)".

But since the Arduino IDE expects COM3, change it: device manager > Ports > DigiX (COM6) > Properties > Port Settings > Advanced > … won't do COM3 says "in use" (by whom).

Nevermind, change IDE to match COM6: Arduino 1.6.5 > Tools > Port > COM6.

Note by default the Arduino IDE expects 9600 bauds so make sure the sketch inits with this as early as possible:  Serial.begin(9600);