Sandboxed re-usable explorations

Let me unpack that : Sandboxed re-usable explorations first starts with explorations. Explorations are short moments in life when I actively try something different from what I have done before. They can be technical or social, driven by profit or pleasure, physical or intellectual. Sandboxed explorations means that those explorations are isolated from each other. If I try something new the result will not tear apart the rest of my life, a technical exploration is not going to make me lose all my friends and a technical exploration is also not going to break my code base. A re-usable exploration means that after doing it, life will go on but if any point in time after I have the need to use the result of that exploration it will be easy to do so. For example a travel would be well documented with contacts to eventually get in touch with. A bit of code will be packaged, presented as an API or component.

Finally a sandboxed re-usable exploration is a safe pleasant moment of trying something new while being able to benefit from it in the future.

Go and create sustainably!

In retrospect this might have been motivated by itself from a desire to never have to repeat the same thought.

Tools or processes supporting the principle

Still mostly descriptive.

  • history bubbles
    • history >> $(date +%s).history.log with pwd conditionse.g. pwd | grep $(echo ~/Prototypes) in ~/.bash_logout
      • ideally something compatible with (reverse-i-search) but without overlapping with my "general" history.
    • see also


Example of slim environment for this specific page (could use a healthcheck to display on all pages iif it is available)

  • Slim container displaying content from its own web server solely for this page.
    • image from
      • could also consider based on Node Alpine
        • larger image (64.5MB vs 186kB) but smaller memory footprint (14.29MiB vs 160.6MiB)
        • consequently running numerous containers might make the Alpine Node more attractive as only 1 image is required for N containers
    • note that the container is truly static, changing the file will not change the content until the container is built again then run, replacing the previous one
  • Aframe discovery demo
    • sandboxed : defined a new markup instead of re-using or modifying the existing
    • re-usable : described the modifications to the wiki and the problems encountered
    • exploration : first time trying to use Aframe on a wiki and to represent data

Potential improved process

  • mapping wiki with github repository and providing a common interface for code created


  • is it sandboxed?
    • If I give myself a 100% during that moment will it messes up other part of my life?
    • If the whole repository doesn't pass the tests after, will it messes up other repositories?
  • is it re-usable?
    • If I come back in few months, can I easily re-use this piece of code in another exploration?
  • is it an exploration?
    • Did I do it before?

How did I get there

Mid-December 2015 I watched Bret Victor's talk Inventing on Principle (his earlier work spotted in 2011). I was impressed but I didn't really get why. When I finally understood why I thought it didn't really apply to my own problems. After few discussions with friends and an intense but painful regarding feedback process VRHackatonBrussels2016 I decided I had to do something about it. I organized SundayGeekBrunch2016InventingOnPrinciple for which I briefly started to watch the talk again. It then hit me that the talk wasn't even about his own abstract principle but something more general. It was about how to actually live your life through a guiding principle. After a brief shower here is mine.

Potential prototypes


See also