My Quora answer that’s pretty popular : (1) Phil Jones’s answer to What do you think computers will be like in 10 years?

Related to my previous story of trying to use the CHIP for work.

This is a $9 CHIP (Get C.H.I.P. and C.H.I.P. Prto)

It runs Debian. A couple of weeks ago, I took one travelling with me instead of my laptop to see what it would be like to use for real work.

I successfully ran my personal “productivity” software (three Python based wiki servers and some code written in Racket) from it. It also has a browser, Emacs and I was doing logic programming with minikanren library in Python. It runs Sunvox synth and CSOUND too, though I wasn’t working on those on this trip.

In 10 years time, that computing power will be under a dollar. And if anyone can be bothered to make it in this format, the equivalent of this Debian machine will be tantamount to free.

Of course most of that spectacular power will be wasted on useless stuff. But, to re-emphasize, viable computing power that you can do real work with, will be “free”.

The pain is the UI. How would we attach real keyboards, decent screens etc when we need them?

I HOPE that people will understand this well enough that our current conception of a “personal computer” will explode into a “device swarm” of components that can be dynamically assembled into whatever configuration is convenient.

I, personally, would LIKE the main processor / storage to live somewhere that’s strongly attached to my body and hard to lose (eg. watch or lanyard). I’d like my “phone” to become a cheap disposable touch-screen for this personal server rather than the current repository of my data.

I bought a cheap bluetooth keypad for about $8. It was surprisingly OK to type on, but connections with the CHIP were unreliable. In 10 years time, that ought to be fixed.

So, in 10 years time, I personally want a computer on my wrist that’s powerful to do all my work with (that means programming and creating music). That can be hooked up to some kind of dumb external keyboard / mouse / screen interface (today the Motorola Lapdock is the gold-standard) that costs something like $20. Sure, I’ll probably want cloud resources for sharing, publishing, storage and even high-performance processing, AI and “knowledge” etc.

And, of course, I want it to run 100% free-software that puts me in control.

This is all absolutely do-able.

Why, yes. This is, indeed, OWL running on the PocketCHIP.

Here’s the story.

I spent 12 days recently, travelling in the south of Brazil and Uruguay border. And I decided, as an experiment, to see if I could live without my laptop. I wasn’t meant to be working, but I always like to keep some kind of SDI / MTC style software on me to make notes and generally think about my insanely long queue of tasks and all my other half-baked ideas. I feel lost without having access to these. And would usually take a laptop, just to keep them near to me.

This time, though, I decided to see how well I could cope with a “device swarm” of very small (and cheapish) tech.

Here’s what I took :

  • The PocketCHIP
  • My Android phone
  • A small, portable USB mouse
  • The rubber-tipped stylus.
  • A 5V mini USB charger that plugs into the wall.
  • An A5 sized paper notebook and pen.

On my trip, I also acquired a small bluetooth keyboard / mousepad that’s actually just a capacitative touch surface with letters marked on it. This impressed me a lot when I bought it at a Duty Free shopping outlet just on the Uruguay side of the Yaguarón River in Rio Branco for under $8. It charges via USB and feels pleasantly heavy and solid, while still pretty small.

Here are some things I found out.

I should note, first, that I’m also pretty much against keeping things on public clouds and other people’s servers. I increasingly want my data to be private, on systems that I control, and mainly synced between my own machines rather than using, say, my hosting provider.

Although I’m far from a satisfactory solution to that, it turned out that the discipline was useful in the sense that I wasn’t as persistently connected to the internet as I’d hoped. And so if I had depended on the cloud I would have been without access to my data more often than I had it.

I also, of course, want to use my own software. I currently have three distinct trajectories of development in this area.

  • Mind Traffic Control, racket-version.
  • The new engine behind ThoughtStorms wiki which is written in Python and uses the light-weight Bottle web-framework. I use this for both ThoughtStorms and a second personal wiki-notebook which is descended from my old SdiDesk notebook.
  • OWL

All these projects are still alive. And my notes and todos (and some more significant chunks of writing) are somewhat haphazardly scattered between them. So I wanted to see how well I could take them on the road with me with such minimal hardware.

Before leaving I updated the Debian on the PocketCHIP and installed the relevant libraries / environments. I already had MTC-racket running on it. And Emacs. Python was there too, but I needed to pip install a couple of standard libraries. Then I could install both Project ThoughtStorms and the Python-served version of OWL. (Spoiler alert : 2017  is going to be a year of consolidation between all these projects, particularly I’m aiming to unify the Python-OWL and Project ThoughtStorms servers into a single code-base.)

I didn’t try installing the Android version of OWL on my mobile, because of … er … reasons … which currently prevent me having a working dev / deployment environment for Android on my laptop. I hoped, though, that I’d be able to access the OWL server on the PocketCHIP from the phone.

Results

The PocketCHIP is a wonderful machine. (And, seriously, a Debian box for $9 just insanely amazing.) It seemed to cope just fine with simultaneously running three Python servers (2 copies of the Project ThoughtStorms wiki, and the OWL server) + MTC. (I just ran unix “screen” on the terminal and ran each in a separate screen.)

Obviously these were not being heavily accessed. (I was the only user). But I’m still impressed.

The weakness of the CHIP is its WiFi. It is very weak. My original thought was to run the servers on the CHIP and then access them from either my phone, or other computers in the places I was staying. But even where WiFi was available, the CHIP typically failed to establish a usable connection with the router.

The only time I could get anything else talking to the CHIP was by turning the phone into a hotspot and then placing that within 10 to 20 centimetres of the PocketCHIP.

This way I was able to access both wikis and OWL from the phone. I didn’t get to remotely ssh-ing into the CHIP to see MTC in a terminal from the phone, but this would have been a particular fiddle and it’s not clear that it would have been worth it. In fact, nothing worked particularly well. OWL’s web-interface is pretty much impossible to work with on a small phone screen. It’s OK on a 7″ tablet, but the phone is way smaller and too difficult to manipulate. And the HTML UI doesn’t zoom in any effective way.

Reading the wiki pages was slightly better. I was surprised, though, how badly the phone handled the fairly simple, static html. I accept that there’s very little fancy “responsiveness” in the TS wiki at the moment. I hadn’t realized how little Chrome would help. On my laptop, ctrl + and ctrl – work beautifully to scale text up and down, reflowing and refitting the text. I have no hard settings for font-size or spacing. The page ought to be easy to automatically resize to convenience.

But pinch zooming a TS page on Android Chrome is diabolical. Not only does it not scale and reflow the text in a useful way. It also seems to remember (or guess) arbitrary different zoom levels for different pages, so you jump from a readable page to another page with illegibly tiny letters to another with enormous text, most of which is off screen. And zooming the menu seems to be independent of zooming the main page text. The whole thing is horrible.

Firefox on the phone is a bit better. You can go into “accessibility” and turn up the text size to full. And then the defaults are reasonably readable and consistent on all pages.

Editing is trickier. And this is somewhat my fault, I have set a fixed number of columns in the text-box in TS wiki which is too large for a phone with either browser.

Overall, I’m disappointed with the phone experience. TS wiki is just about readable on Firefox. But it’s useless for doing any kind of work. And horrible on Chrome. OWL looks OK on both browsers, but is too fiddly to actually edit.

I need to radically rework the UI for both these projects.

So I went back to see if I could actually look at these web-served applications on the PocketCHIP itself.

It turns out that OWL works surprisingly well with the surf browser which comes pre-installed … as long as you use a mouse!

The touch screen even with a rubber-tipped stylus isn’t viable for navigating and editing an outline. But attach an external mouse to the USB and it’s surprisingly usable. The PocketCHIP keyboard isn’t great for a lot of writing, but for short items in an outline it’s viable.

TS Wiki is also fine to read. But for some reason the text-area is coming out black, with black text. (I’m pretty sure I’m not setting this explicitly, so I assume it’s a bug in surf.) You, therefore, can’t edit the wiki with it. But reading is an acceptable experience. Once again, a mouse helps, but you can just about get away with the stylus.

The bluetooth keyboard I bought paired fine with the phone. But with the PocketCHIP there were some issues with the mapping between some symbols. I couldn’t find any combination of keys to make a backslash for instance. And sometimes the shift wouldn’t work. Also the bluetooth connection kept dropping. I found myself continually swapping between the PocketCHIP’s own keyboard for typing short commands with a lot of non-alphabetic symbols, and the bluetooth keyboard to type paragraphs of text. It was just enough to get some work done, and the bluetooth keyboard was just better enough to make it worthwhile, but it wasn’t really a viable solution.

Aside

This trip I also got interested in Logic Programming and tried out the Python Minikanren library, logpy, on the PocketCHIP. Unsurprisingly, it worked as expected. But, again, that is kind of startling when you think of it.

Conclusion

Well, this stuff works. If the PocketCHIP just had better wifi / bluetooth connections, then it would be a serious possibility to do some work on. It might be that a software update fixes the power-saving that may be weakening the wifi.

But it’s not something that even I can use yet.

Some of that is in my hands, of course, one task is to tweak the TS Wiki UI to ensure that the text-area is readable in surf. That would at least mean that PocketCHIP could be used (if uncomfortably) for working on my notebooks.

It’s not all working yet … but it’s getting closer.

Posted in Me.

You all probably knew where this was going, right?

Mind Traffic Control (Racket version) running on PocketCHIP
Mind Traffic Control (Racket version) running on PocketCHIP.

Of course, it’s been my priority to run the new MTC on the PocketCHIP. And it runs fine, without any special conversion; just needed to figure out how to install a library it depended on without going through drracket.

Now I’m off for my celebratory bike ride. 🙂

 

 

Save

Posted in Me.

Yahoo Pipes may be dead, but Node Red seems to be the device swarm orchestrating, data-flow programming tool I was hoping it might evolve into.

It’s free software, it runs on everything including RaspberryPi and talks pub-sub protocols like MQTT.

 

Source: Node-RED

Posted in Uncategorised.

Third in a series (#1, #2) of questions occupying my mind at the beginning of 2014. Which may (or may not) inform what I’ll be working on.

3) How can we program on tablets?

I’m now a tablet user. I became a tablet owner at the end of 2012. For six months I played around with it, trying a few Android programming exercises. But I only really became a regular tablet user half-way through the year. Firstly when I put Mind Traffic Control into a responsive design. Secondly when I bought a couple of e-books. And I only really got committed when I did OWLdroid and coupled that with btsync.

So – somewhat late to the party, I admit – I’m now a tablet enthusiast.

And so my question is, how the hell do I program on this thing?

There’s a trivial answer to that question : get an external keyboard, an appropriate editor / IDE and treat it like a normal computer with a small screen. I can do that. I’ve worked a lot on netbooks and small screens don’t freak me out. But that’s not really what I mean.

Because tablets aren’t meant to have keyboards. And a computer without a keyboard challenges one of my deepest held programming beliefs : the superiority of plain text.

Plain-text is so flexible, so expressive, so powerful, so convenient to work with, that I’ve always been highly sceptical of those who want to do away with it. But on a keyboardless computer, it’s a different matter. Plain text isn’t at all convenient without a keyboard.

Especially the text of programming languages which makes rich use of another dozen or so punctuation symbols beyond the alphabet and numerals. And where manipulation relies on cursor-keys, shift and control, deletes (both forward and backspace), page up and down, tab-complete etc.

And yet tablets are becoming ubiquitous. Increasingly they’re the target of our programming, and the tool we have with us. So how are we going to program in this new environment? With multi-touch or stylus but no keyboard?

I have yet to see anything even vaguely plausible as the revolution in programming “language” we’re going to need for this.

I don’t think it’s the “Scratch”-like or “App Inventor”-like “stick the blocks together” languages. The problem of programming on tablets shouldn’t be conflated with the problem of teaching novices to program. (Which is what most visual programming environments seem to be about.)

One issue with that kind of system (and other “flow-charts”) is that blocks need to be big enough to be easily and unambiguously manipulated with fat fingers. But to be decently usable, a programming system should be able to have a reasonable density of information on the screen, otherwise you’ll spend all your time scrolling and forgetting what you’ve seen. How do you resolve that tension?

Perhaps “data-flow” programming of the Max/MSP, PD, Quartz kind. Piping diagrams. Process Modelling packages have something to teach us about orchestrating in the large. But they are shockingly clumsy for certain fine-grained activities that are expressed easily in text. (Eg. how the hell can you talk about tree-shaped data or recursive algorithms using this kind of piping model?)

So I don’t have any information about who is doing interesting work in this area. (Aside : while writing this post, I thought I’d consult the collective wisdom on StackExchange. Needless to say, my question was immediately shot down as too vague.) But I’m now very curious about it.

Posted in Uncategorised.

Quick Note : I just had a revolution in my thinking, triggered by Enso but influenced by several other recent trends.

You write Enso “extensions” as XML-RPC servers sitting on your local machine, register them with Enso and it calls them using XML-RPC. I tried the example from the tutorial and it’s very cute and simple. So I’ve decided this may be a way forward for the dilemma which has kept the “new SdiDesk” on hold for several years(!!!)

If you remember, the issue has been whether the new SdiDesk should be a “web”-application (accessed through the browser) or a desktop application? And how to implement the UI.

The problem with the “browser” answer has always been : “but how to do the network diagramming bit?” – which requires interactive vector graphics. SVG doesn’t seem quite stable or cross-browser enough. Canvas isn’t cross-browser. Flash is proprietory.

The problem with the “desktop application” is, well, the many rival Python GUI libs with different degrees of maturity. And the question of getting them to work cross-platform.

A meta-problem : I just don’t have time and energy to go through learning lots of different GUI frameworks to decide which I want to use. And the ideal answer to the browser / desktop question is probably “both” which doubles the amount of work.

In fact, one of the motivations for GeekWeaver is to see if I can use it define a higher-level UI description that can be compiled down into both XHTML and a GUI widget-set.

Of course, with XUL, Open Laszlo, Adobe Flex, XUML etc. lots of people have been looking at something like HTML for defining desktop apps. too, but the free Python frameworks don’t seem to have caught up with that yet. XUL sounds most promising especially with the open sourcing of Active State’s Komodo … but that’s also a big complicated thing to even start looking into.

Anyway, inspired by the Enso extensions and Bruce Eckel’s interesting example of hooking up a Python XML-RPC server behind an Adobe Flex application I’ve been wondering about blowing the project apart entirely into a number of services connectd only XML-RPC or something more ReSTful.)

So there’ll be a WADS (SdiDesk PageStore) service, a GeekWeaver interpreter service, a “user navigation history service” etc. Even the glue which ties all this together will be another service that’s neutral about the user-interface. Effectively the model, view and controller will be completely separate programs. (I know, I know 😉 )

Then there’ll be a variety of different types of access with different UIs.

Now that Adobe’s AIR has put Flash on the desktop and made it a serious rival to the Java virtual machine – I *am* tempted to put some time into learning it. It would give me a reasonable GUI widget set (including TreeGrid, yay!) and the vector graphics needed for networks. It will run both on the desktop and in the browser and on Linux, PC and Mac. The tools are free-as-in-beer (Flex beta) or free-as-in-speech (Open Laszlo). It’s also possible to imagine generating the Flex XML or the Open Laszlo format directly from GeekWeaver. (Aside : I wish ActionScript hadn’t borrowed quite so much from Java, but still, I’d only be using it for the front-of-the-front-end UI stuff.)

Then I want to experiment with Enso access – for example, Enso commands like “page HelloWorld” or “pagehistory ChocolateCake”

And there’ll be web-browser access probably through a “gateway” that accepts http requests and spits out HTML for a browser. The only thing I don’t know is whether I *really* should be using WSGI somewhere here.

Anyway … that’s a quick update of my thinking this week … tune in soon for the next GeekWeaver release (really, it’s coming together, and gonna be very powerful). Then it’s back to work on this larger project.

Posted in Uncategorised.