Learning JS stuff:

• Bootstrap for UI/widget/look.
• Embed JS for "application" framework (what does it bring? How's that MVC and testing really useful?)
• Kinetic for HTML5 canvas.

Ideas:

• Block editor. Saves locally on server.
• Dashboard showing server data / state. Think piscine enregistreur.
• [...]

Speaking of piscine enregistreur, I don't think I can support velleman's USB stuff on an RPi (never got motivated to find how to deal with the driver), so look into other venues to have voltage measurement.

Web ide idea: not a full project per se, just a server side hack.

Did some work on the Music App this week-end: I kind of like and hate the little script language implementation. It would be interesting to formalize its implementation into a design doc and write a standalone library for it, working on separating "core" language from app-specific extensions.

[update 2014-03-09, here it is: NovaScript [idea]]

Follow up to the last note about the hint documents. Generally speaking I should clearly organize documents using a category system. The 'ideas' folder is such an attempt, but maybe some large categories in the title would help:

• Brainstorming or Idea or Concept: live log about a concept or idea, unstructured.
• Research: structured with version, or unstructured with live log. Explores one singular topic. Similar to brainstorming but more focused on a single topic.
• The separation between research and brainstorming is fuzzy. Brainstorming kind of implies the document is unfocused and quite exploratory. Research kind of implies I already know more or less what I want to talk about.
• I don't like the word "Brainstorming." In fact I don't like any of these qualifiers here.
• Design doc: structured, not a live log. Use versions to capture evolution. Describes one specific project, in a singular version. Discussions go in another document (concept one).
• Implementation: companion details about a single design doc version. Unstructured, live log. If one topic gets too large, extract it into a research document.
• Platform or Overview: large description about a given system that might encompass several projects. Structured, with versions. Ongoing discussions go into a live research or brainstorming document, the overview document captures the summary of a potential state.

Applying this to the hint thing:

• "Platform hint" becomes Brainstorming on the ikaria platform.
• Overview: Ikaria v1
• Overview: Hint language v1. --> design doc v1.
• Research: feedback on clojure.
• Research: immutable data types for closures.
• Idea: Cloud Bus --> Design doc v1
• Brainstorming: Robot game. --> Design doc v1 --> various design doc links to subprojects.

Also go back to older documents and rename them as clearly obsolete.

[...]

I think I'll settle for [Idea] and [Research] for now.

Part of the goal is to have a more systematic approach. Most of my documents are merely exploring an idea for an app or a library and are often expressed as a list of "specifications" that combine both desired features and potential implementations. One goal would be to have a more structured and formal approach where there's first a discussion document that explores possible variations and then settle down on one particular set of features & implementation.

Phase 1: A project description starts with an [Idea] document.

• Often I just stop there or have various iterations on the idea. That can go into the same document.
• If at some point I decide I'm taking a radically new direction, I should make a new version (so Project Foo v1 [Idea] ⇒ Project Foo v2 [Idea].) Make sure to link to the previous one for reference.
• Many times a document would describe an idea along with a potential "specification" overview. The pattern would be to add "Spec" to the doc title, but it's not a category by itself, it's still an idea unless it's formally rewritten as a design doc. That's because such documents are generally live documents where the proposed spec is part of the exploration, and not necessarily final.

Phase 2: If the project starts to get serious enough, try to stabilize one version of it.

• This becomes an [Overview] document or a [Design Doc] document.
• These documents should describe the project fixed at a particular implementation. If it turns out to not be satisfactory, amend the [Idea] document with an on-going discussion and continue stabilizing the idea.
• Only a minority on medium-to-long term "serious" projects would get that treatment.

Git?

We have git at home.

Looking at the various Hint documents, it's a bit of a mess: As explained in the [Hint Platform] document, the various Hint docs are mixed because some define what I want to do "with Hint" rather than "for Hint".

Namely [Hint Platform] describes how the discussion should be split into different projects:

• Hint documents should be purely about the language and the VM itself.
• Ikaria should be the umbrella platform, the shell that _uses_ Hint.
• Cloud Bus is a separate project.

One cleanup operation is to take the old [Hint Platform] and pretty much rename/move it into an "Ikaria Platform" document. Then the Hint doc folder should only have Hint material focusing on the language, its syntax, and implementation.

Given that, the goals are not quite changed:

• Target apps are still Black Editor, Nerdkill/Asqare on top of Hint.
• Apps are networked using experimental versions of Cloud Bus.

Last week, experimented with Robolectric.

Looking at modernizing Asqare and Nerdkill using the look and feel of Puzzle. Ideally these should be made on top of a generic app shell, customized using assets and scripting.

Step 1: This is different from a live editor. Here the script and assets would be transformed into a native android app , directly in studio.

Step 2 is the robot game idea where a game editor app is used to produce mini games.

Need to better spec those. Step 1 can be combined with Ikaria. Testing should be a first class citizen, especially to abstract all ui using some kind of MVP pattern.

Finished Set Puzzle phase 1.

• Created a full features MVP (phase 1), presented it.
• Could make a variation of such, from the same base. Code name is "taz".

Reworked LibUtils:

• Googlecode main branch is the C# version Lib1+Lib2 with AndroidAppSkeleton.
• Googlecode "android-lib" is the java lib for Studio that provides Serial + utils.
• ⇒ Implement new file-storage class with possible direct access.

Idea: use Nerdkill to experiment with Google Play Game APIs.

• Revamp app to have the holo-light look & organization from Set puzzle.
• Add leaderboards.
• Add ludicrous achievements ("played the app for 5 minutes", "launched the app".)
• Multi-player.
• Add ludicrous IAB items.

Want to rework on the foundation of black-editor.

Pending projects that need some love…

Web App idea: Val clone

• Web based (phase 0)
• Optional android client (phase 2)
• 2 implementations strategy in mind:
• As an Go or Java/GWT based AppEngine app, with AppEngine data store.
• As a GDrive app using a specific Drive document as the backend.
• As a learning tool, I could do the following:
• Full HTML5 (?)
• A Gdrive-app
• Use Dart (which has google-drive APIs libs)
• Custom drive document type
• Note: gdrive API no longer provides a spreadsheet API.
• Offline Chrome App would be nice but seems like a security risk.
• Make it a Chrome extension. No local storage, no full listing, just a little popup for keyword search => result.
• Random bits:
• Model is a pure key/value list: name ⇒ { password, date when set }.

For the fun/obscure reference, call it "Slowdive… because it ain't no bloody Valentine".