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);

How to currently install/build go 1.5 from source on Linux:

$ cd ~

$ git clone https://go.googlesource.com/go

$ cd go

# create the go 1.4 bootstrap using gcc

$ git checkout go1.4

$ ( cd src ; ./make.bash )

$ mkdir ~/go1.4

$ cp -rv bin pkg src ~/go1.4

$ (cd src ; ./clean.bash )

# build latest version

$ git checkout go1.5

$ ( cd src ; ./all.bash )

$ export GOROOT=~/go

I've added a new idea/research page for BX07.

I just realized the scope exactly covers Ikaria v2 and more or less  v1:

• Both are "skeleton" apps, destined to be reused for future projects; some kind of framework/sample to avoid re-writing the same thing all the time.
• Both are supposed to be rather horizontal and cover a lot of areas, namely server-vs-app, remote sync/cloud, IAB & licensing.
• Both are supposed to be "validated" by extensive testing rather than actual implementation.
• Both will not happen for exactly that reason.

The realization is that I have lots of ideas and thus I'll tend to focus on the actual results rather than the theoretical ones -- which will best remain as doc write ups.

There's also the mythical idea that they don't get implementation because writing software is hard and time consuming and thus if I had a framework to work upon, it would make everything more smoother.

The former realization seems valid, the latter is a load of BS. Frameworks don't make things easier -- they canalize in one direction and make it harder to be flexible and do things outside of their scope. Since my ideas are generally quite broad and volatile, attempts at frameworks don't help -- e.g. RLib for example.

Once again I have too many projects going on. Here's a summary of the current projects with a quick summary state, more or less in the order in which I would like to prioritize them:

• The Cleaner -- ongoing. Slowly put on pause after vacation, should go back to it.
• NovaScript v1 -- pending. Taking too much time to write tests, not clear of the direction; I had realized that v1 was not what I wanted; since it's still embryonic and experimental, modifying the concept to fit my needs is part of the project goals.
• Google Code cleanup -- not started. Got overall idea, need to follow through.
• Train stuff -- ongoing. Several things: exploring ideas right now, nothing concrete.
• Got the JMRI server part setup so I don't need to make my own.
• Next step is arduino control of one turnout + integrate in JMRI.
• Next step is front panel tablet / wooden console + expand to all layouts.
• This is a long term overall project with many small projects.

I also need to pipeline things better. E.g. for The Cleaner I can finish the widget part and a prototypal customizable UI, then it will be waiting on DK's side. During that time I can focus on train/arduino stuff.

For NS, I need to rethink the whole thing.

The initial design was for an experimental v1 that would not be too useful yet would give me some directions. That's good and the v1 implementation proved interesting and showed some issues, which I addressed as I went, but I need to speed this up if I want to see the rest of the unforeseen issues -- it just takes too much damn time to do it properly.

Since I don't think of v1 has being ultimately so useful, should I probably not focus on "doing it right" and instead cut corners and implement it faster? One issue with that is once I specify a v2 as addressing all the issues found in v1, it will also take forever to do it right unless I can make it an evolution. So whilst I need to speed up v1's implementation, I should not ruin it because I might want it for later.

Another approach: scratch v1 and specify v2 directly, then rework v1 as a subset of v2. Then implement v2, with the optional parts left out at first.

The problem is that the current implementation of v1 has focused on the parser, but that's only a minor part of it. No work has been done on the runtime and the text vs graphical editor and then there's the larger cat-in-the-bag issue of which underlying language to use.

Google Code transition:

• Google Code will close, with enough time to migrate projects.
• GitHub sounds like a logical choice.
• Price model is based on number of private repos, with unlimited collaborators.
• BitBucket is the other choice.
• Part of the Atlassian group.
• Private repos are unlimited even in the free plan.
• Price model is based on the number of users, with unlimited repos.
• A users is "someone with r/w access to your private repositories"
• Free model is up to 5 users.

Pros/cons:

• GitHub is more suited for high visibility + trivial project cloning.
• BitBucket is better for my personal stuff -- I want low visibility including private repos which I do not have right now.
• I don't need users (just me, maybe an rdrrlabs repo)
• With BitBucket, I might want to try to mirror my home repos as backups.

List of Google Code repos and migration path:

• Most of my GC repos are here to "reserve" a namespace and project name.
• Most of my GC repos are here to serve as an online backup. Many of them I do not wish to expose so I jungle around to only publish "public" stuff in them.
• This isn't needed in the GH or BB model since each project is under the user's namespace.
• I'd suggest going with BB because I mostly want private repos.
• Most repos would go into private mode for pure archival purposes, no activity.
• Check whether a repo can be changed from private to public at any time or is fixed.
• Only expose a minimal set of "useful" repos.

I'd like to do a parallel research document on language design.

Right now I have some ideas for Hint, which is still very vague and not well formalized. It's a bit of a catch-all. So instead I did a subset with NovaScript, whose version NS1 is really limited -- the main purpose is to remember how to implement a language and interpreter, then have a more useful NS2 version. This isn't Hint at all, although hopefully some things could be reused.

Hint discussion suffered from being both a language discussion and a platform discussion but I believe I cleared that one out, or did I?

Anyhow, the point of this snippet is to remember that, in an ideal version, Hint would have elements of:

• Actor model: each "class" or module is independent and calls are considered RPCs.
• Distributed vs non-distributed and "mobile" actors. There can be several VMs distributed on different hosts and then freeze/move runtime modules around.
• Behavior Driven Development -- in the very very early Hint discussion one of the ideas was to make it trivial to add testing.
• One way is the classic unit test where each function has its associated test, but in practice this is seldom useful and unit tests quickly turn into larger behavior tests that encompass a set of functions.
• Small functions can be treated as mathematical functions, with some inputs and output automatically compared.
• More often what needs to be described is the behavior of a whole or part of a system, but it gets tricky with side effects and generally the test itself is costly and confusing to write. Not to mention that all corner cases are hard to predict and test.
• Still the idea is that this is highly valuable and ideally would be part of the source and not an on-the-side after-thought.
• Continuations built into the language, either like a call/cc.
• Coroutines, iterators and generators.
• Various levels of implementation using extensions to a unified language. That's the point of the hint levels (0=assembly, 1=C/java like, 2=interpreted). Similarly some of the concepts like distributed actors are not mandatory.

Whenever possible I should look up definitions in c2 and match their name patterns.

So part of this impacts both the platform and the language (e.g. BDD, mobile/distributed actors.)

Some of these are things I have absolutely no idea about them except they seem like good ideas.

I've never used call/cc -- although goroutines and closures are familiar. I certainly have no idea how to implement them, which makes it much more interesting to even think about.

BDD and testing are in a slightly different category -- there are many languages that have support for unit tests and such. The question is whether I can make it attractive and efficient for me to use a-priori rather than a-posteriori. My current attempts at using UT are more hindering my development style than enhancing it.