Today I killed the old Mind Traffic Control on Google App Engine. And replaced it with a new, fairly basic, site. (Though one that’s quite pretty, in a Packt Publishing kind of way.)

This is the beginning of a whole new MTC ecosystem.

1) I’m no longer interested in hosting your todos on Google App Engine. The only functionality that’s left on the site is the “export”. You can get the tasks you put into the old MTC in one of .txt, .csv or .opml formats.

.txt means you can use either an ordinary text editor, todo.txt or the new command-line based mtc program on your own machine.

.csv means you can use a spreadsheet if you prefer

.opml can be read into an outliner such as OWL.

2) The site has a new mission. Right now, it’s simply pointing visitors to the two pieces of software that I use to manage my todos and information : MTC command-line (in Racket) and OWL (in its three different versions : desktop, Android and web-served).

These are currently all simply source-code, hosted on GitHub. (Both MTC-racket and OWL are free-software, under the GPL).

It’s a geek view. But going forward, I’m going to be preparing, packaging and documenting these for actual users.

3) Right now, I still don’t know the relationship between MTC and OWL. They’re different programs, with different “mind traffic geometry”, in different languages. But I use both and I’m constantly musing about how they can and should interact.

The only thing which is clear to me at the moment, is that they should be brought together under the common Mind Traffic Control “brand”. As a statement of intent.

Well, I tend to think of “Project ThoughtStorms” as the developers’ view on my knowledge management / personal productivity software. While “Mind Traffic Control” is the user perspective.

There’s more to it than that. Project ThoughtStorms covers my experiments and add-ons to the Smallest Federated Wiki and thinking about wiki in general. MTC heavily emphasizes the dynamic flow of tasks. But that’s the broadest overview.

In practice I’ll continue to refer to MTC-racket and OWL within the contexts of both Mind Traffic Control and Project ThoughtStorms.

5) I am VERY happy to be deleting code. And collapsing several different overlapping ideas and codebases into … er … fewer. It’s a therapeutic decluttering that’s clearing space in my mind, and helping me focus and drive the surviving projects forward faster. It’s good.

But there is just a slight twinge of sadness. As I realize that this is a mile-stone in letting go of Python, a language I had a long and passionate engagement with. Both the old MTC code-base AND the server-side PageStore of OWL are Python.

But since porting OWL to Electron I can see that its future is very much in the Javascript (node / CoffeeScript) camp. Meanwhile the new MTC codebase is in Racket. And my latest quick conversion script persuades me that Racket is a good language for other small-scale tools. I have about a dozen of them in Python. But I’m pretty sure that new development in these areas will almost certainly be Lisp. (Racket or Clojure).

(Actually there is a project that’s still in Python where you’ll see some further development soon … but I’ll leave that to another post.)

No New Year’s Resolutions or even questions this year. But as an honorary Brazilian, my new year doesn’t really start until after carnival, so now would be the time for it.

However here’s a quick update. The answer to the old MTC question is now resolved for me.

It’s time to put the bullet into the Mind Traffic Control that was. The case against it is overwhelming. MTC was written to learn the exciting new world of Google App Engine and the style of web programming of the mid to late 2000s … Python, something almost Django-like (ie. Rails-like). Backed by a relational database-like thing.

It’s a world I later fell out of love with. Python and Django are … fine. But they aren’t what continues to excite me in 2016.

I toyed with Meteor. But how to host on GAE? And, anyway, in 2016 I have the sickness … I just AM a Lisp programmer. Not necessarily a very good one or particularly experienced one. But I’ve succumbed. This is what I’ve been looking for all my life. It’s what I want to do, going forward.

So a rewrite in Clojure / ClojureScript. That presumably can be hosted on GAE. And I can have a wonderful new reactive UI with Om.

Yes … I’ve been playing around with it … but …

But then again. The old GAE database isn’t a good match for the circular queue of MTC. And worse, I’m not keen on storing my personal data on someone else’s cloud. Yes, it would have to be a single-page app. Yes, it ought to talk to remoteStorage and offer Dropbox etc. too.

These are all wonderful things and yes I am playing with them and want to use them. But … MTC? MTC is a todo-list app. There are a million and one such apps. They’re the “hello world” of browser-based GUI frameworks.

I’d love people to experience what’s good about MTC. But is it likely? How would I cut through the noise of those millions of alternatives? (Some of which are very slick.) Could I really get any kind of audience for a todo-list app in 2016? Does it make sense to put my energy in this direction?

And then again … if I’m going to boot up my browser and run a local server, then I have OWL.

OWL is great for more extensive, smart-disorganized note-taking. It’s just that it doesn’t have some of the charms of MTC. It’s not dynamic … tasks sit around and clog up the pages. You have to navigate around to find them. Sure, it’s pretty easy to navigate around – wikiness makes complexes of documents into small-worlds – but it’s still lacking that immediacy of the river / feed of tasks.

So last year I was fairly convinced that MTC was just going to become OWL hosting. But that isn’t what happened. There is still something to MTC, to the todo-queue concept. And it has resisted being subsumed within the OWL paradigm. My early enthusiasm for OWL was wrong about this. And my initial intuitions vindicated.

So what next? These last months I’ve been drawn back to the command-line. And also to Racket. Which compiles to fast executables. (Clojure is great, but the JVM does take a long time to start.)

And I’ve been admiring (again) todo.txt. Which in many ways is the right approach.

And so … I present : the new Mind Traffic Control. Which is, I admit, nothing but a short Racket program. That reads a file called “todo.txt” from somewhere on your machine. And does MTCish things with it.

Philosophy :

– it’s (right now) a convenient command-line tool.

– it’s compatible with your existing todo.txt file. It doesn’t do everything that todo.sh does. But it has its own tricks.

– in particular, it keeps the queue-ness. You only see the latest item. And most of its commands are about flinging tasks you don’t care about now into the future where you don’t have to think about them (yet).

– obviously it loses a lot of what made the GAE-hosted, web-based MTC interesting. There’s no delegation to other users etc. But I’m not sure many people used that.

– very simple. very minimal.

I have to say … I am EXCITED by this … more excited than I’ve been by any potential refresh I could have made to the old MTC paradigm (even rewriting more or less the same thing in Meteor or ClojureScript / OM). This is fresh and different.

The Future : MTC has a new mission.

Firstly it’s going to be MY todo-queue tool. Previously, the web version was always thought about in terms of “what might people want?”. In practice, almost nobody else wanted it. Now MTC’s mission is “what do I need from a tool?” What maximizes my convenience? I like the command-line. I’m comfortable there. That’s where this is going to be.

Secondly, I’m not that into task-management software. I want software to help me DO stuff. And the focus of MTC going forward is going to be to add features to help me do. For example, I have an item with a link I wanted to read. I now read the link and want to post it to a link-blog. Can that feature be added to MTC? Why not? I come up with an idea for a new project and start putting todo items about it into MTC? Can MTC create the project directories for me? Can todo items be exploded into actual scripts? Within this environment? Once again, a direction worth exploring. (In a sense, MTC with extra tools could be seen as exploring the coming UI paradigm of bots in rivers.)

Syncthing is now my synchronization solution. I don’t think I’m going to worry about clouds and hosting, because I want to use horizontal P2P syncing as the way of making sure the queue is on all my devices.

The original MTC site will be updated shortly. You can, already, export your data from it in todo.txt format. That is now the recommended solution for MTC users. The new version of the site will probably continue to let you do that, without adding anything new to your queue. But it will give guidance on how to install and use the new software.

From hereon-in it’s all Lisp. I’m getting more fluent in Racket. I do have a nagging feeling that maybe I ought to convert to Clojure-like dialect. Which would allow me to use the same code in the browser, on a node server or even compiled using Pixie-Lang. I’m still thinking about this and will make a couple of small experiments in the near future and I’ll pay attention … will other people pick up the Racket code? Will I find myself with a new compelling reason to have MTC back in the browser? Is it worth moving to Rackjure to smooth a potential future port? Right now the code is still trivially small enough that I could port relatively quickly. But I’m watching.

Well, er … yes … the truth is, I am now using OWL very heavily. Pretty much every day. And I am putting to-do lists into it. All I can say is, it’s working really well for that. Possibly because I don’t try to keep everything in one big hierarchy. But have different pages for different aspects of my life. So the to-do lists are rarely more than 2 levels deep. And I think the longest one is about 20 items.

It’s a really comfortable combination of geometries : easily navigable wiki pages at the large-scale and outlining at the small.

There’s a fairly complimentary review by me on the Amazon site, which should be read in light of the fact that I’ve been watching this book grow over the last few months and sending comments on the drafts back to Bill. So I have some personal involvement here.

I stand by the message, though. That this is an important book for someone to write and has a wealth of interesting ideas and references. It’s well worth a couple of dollars and an hour to read if you aren’t already immersed in Bill’s world.

However, as I pointed out some time ago, wiki is surprisingly bad for authoring longer texts that structure an argument for a reader. And, to an extent, the style of this book betrays its origins as a set of notes on wiki-pages. Both in the way that it’s fragmented – forcing the reader to navigate links rather than follow a narrative in the text – and in the way you see history sedimented. What makes wiki bad for authoring structure is that, at least traditionally, it offers little support for revising / refactoring. What often happens on individual wiki pages is that you write something substantial when you launch a new page, and then in the flow of updating, just paste extra links, ideas, thoughts at the bottom.

That soon leaves you with longish pages which are effectively little rivers, except upside-down with newest stuff at the bottom and the oldest at the top. Which can be fascinating for archaeologists who want to reconstruct what you thought at different times in the past, but doesn’t make them particularly useful as “book chapters”. Pages are both too narrowly specific (they only talk about one thing) And too full of historical cruft. Yet it’s very tempting to see them as the basis of such chapters.

And there’s nothing much to help you transform / refactor standard wiki-pages into approriate segments of a longer text.

As an aside, the Smallest Federated Wiki’s refactoring turns out to be highly flawed in that it enforces a rigid idea of paragraph in the structure of the document. In practice, when writing and rewriting you often want to grab and move different sized chunks of text. Sometimes single paragraphs, but sometimes just a couple of sentences from one paragraph to another. And often a larger chunk of three or four paragraphs. SFW makes single paragraph movement between pages or re-ordering very easy, but at the cost of making single sentence or multiple-paragraph re-ordering far more difficult. There’s no way to select / cut / copy / paste chunks of text with arbitrary boundaries the way that an single “edit” box for the whole page would allow.

So Bill’s is a nice book. And it’s a worthwhile read. But it hasn’t escaped the curse of being wiki-written. There are still moments when you encounter that sedimented history and think “if you were writing this from scratch, that wouldn’t be there”.

Still, I think it’s going to be interesting to see how successful this wiki-style is in an e-book format and for an e-book readership. One advantage of e-book readers is that at least they support hyperlinks, so the contents in the book can be surfed and meandered through. OTOH, is that the pattern of reading that people expect or want when sitting down with a Kindle? It’s in interesting experiment.

Thanks to Bill Seitz I picked up on a Giles Bowkett post I’d missed a couple of months ago which compares the loosely coupled asynchronous style of development that companies like GitHub both promote and live, with the intensely coupled synchronous raids that occur in online game-worlds.

Bowkett seems confused by the apparent contradictions between the two. And yet obviously impressed by the success of both. He wants to know what the correct synthesis is.

That really shouldn’t be so hard to imagine. The intense coupling is what happens in pair-programming, for example. Or the hackday or sprint. Its focus is on creating a single minimum product or adding a single feature / story to it.

The right synthesis, to my way of thinking, is intense / tight / adrenalin fuelled / synchronous coupling over short periods, where certain combinations of talents (or even just two-pairs of eyes) are necessary. And loose / asynchronous coupling everywhere else. Without trying to squash everyone’s work into some kind of larger structure which looks neat but doesn’t actually serve a purpose.

The future of work is highly bursty!

It shouldn’t surprise us, because modularity is one of the oldest ideas in software : tight-cohesion within modules of closely related activities. Loose and flexible coupling between modules. It’s just that with these work-patterns we’re talking about modules in time. But the principle is the same. The sprint is the module focused on a single story. The wider web of loosely asynchronous forks and merges is the coupling between modules.

it would depend on my users being dumb, and as I said earlier, my users are anything but. They’re the smartest people on the planet and I want to keep it that way. And I think anyone who makes software for dumb people in the end gets what they deserve. 🙂