Sunday, 29 December 2013

On Flow-Based Programming

A late answer to Daniel's Post "The Future of Computing"

Since some time I am intrigued by Flow-Based Programming (FBP) programming. It feels natural to me because I've worked with vvvv back in university, doing some interactive work, early on with Node and Erlang, and share a general interest on the life cycle of systems, flow in architecture and how to bring process and flow into model versioning.

Daniel points out the social aspect to FBP when he links it to Bret Victor's "Future of Programming" arguing we should (I paraphrase) bring computing technologies to people rather than people to technologies. The way Alex puts it is a bit more extreme: "People shouldn't have to learn to code to apply software to these problems". The question is not technology, or how we present technology. There will always be professional engineers that like to use vim, and there will always be people who like to learn the quirks despite their original profession. And technology has already become a lot more accessible, easier to learn and distribute. On the other hand, however, people don't want to think abstract, externalizing their creativity into a formal language.

In Code, Georg Vrachliotis tells the story of how Architecture scholars reacted to the rise of the computer. From the Architecture Machine and the 1970s statement "We want to arrange matters so that the computer can be used as naturally and easily as a pencil" all the way up to the contemporary view of code and architecture cross-pollinating each other, at the section of programming a drawing, with technologies like CAAD - much like visual programming or FBP.

We can't bring technologies to people, neither can we bring people to technology. We can create, however, a new space that provides the tools for people to pick up and decide how much they want to engage with technology. We have to build systems and technology that is both easy and versatile, comfortable and challenging, stable and fluid. By doing so we avoid the System design trap - the more we engineer, the less natural a system feels. It reminds me of one of my favorite quotes from John Gall:
Trying to design a System in the hope that the System will somehow solve the Problem, rather than simply solving the Problem in the first place, is to present oneself with two problems in place of one

UPDATE:  On the discussion of common sense and using Nudge as a way of "Utopian Realism" I like to add the beautiful end of the Manifest for a New Realism:
Enlightenment still calls for a choice of position  and faith in mankind, in knowledge and in progress [...] What are needed are knowledge, truth and reality. Failing to accept them [...] means pursuing the ever-open alternative proposed by Dostoevsky’s Grand Inquisitor: the path of miracles, mystery and authority. 

Friday, 27 December 2013

E-Books and Tablets are so 2013.

In Autumn I decided to switch over to use a tablet  (Nexus 7, maybe part of the problem) exclusively for private work. At the same time I decided to use E-Books, mainly because I had read so many bad books I threw away that keeping paper didn't make much sense anymore.

From Jan 1, 2014 on, I will switch back to a laptop and paper books for the bulk of my work. Here's why.

Why I dropped the Tablet (pun intended):

Main reason: I multitask. I know it's not efficient. Probably it's same kind of boredom that drives me to it, as I am certainly not suffering from ADHS. Unfortunately I am not a stream person, either. Tablets are made for streams, executed one by one, like packet switching or serial monogamy. They are built for either technology agnostics (think iPad for seniors) or very organized cloud-only stream-switchers (think Ben). Sure, some solutions like Cover try to address this with contexts, but it's still single task.

Having more than one E-Mail open? More than one browser instance? Switching between a Spreadsheet and a PDF staying at exact the same spot? Want to write an article with references (leaving aside there is not a single good quote-taking app out there)? Undo after you accidentally deleted all text? All that is currently impossible with the current state of most Android and iOS Apps. It gets worse with offline or limited connectivity (Hybrid Apps just crashing, Google Maps stays blank), where it's literally impossible to do research over more than a few browser tabs. Add technical problems (no ESC key when Apps freeze, Android updating in background just when you need to show your plane ticket) and questionable product decisions (Apple disabling USB Sync) it destroys all the productivity added in the first place.

I was positively surprised with the text input (thanks to an IVSO keyboard and Markup editors), on-screen note-taking, reader capabilities and TV connectivity (ChromeCast). Really, I loved the Nexus. The problem is though, it only works 90% and drives you crazy the other 10%. It's those 10% that tests usually not mention but made me unpack my 5-year old PC and get workin' again. Efficiently.

As for E-Books:

Main reason: No experience. I do read for both pleasure and knowledge extension, but the latter I primarily do via Readers like Pocket. A book is usually a long text I want to work with, i.e. a text I need to understand, cross-reference, highlight, read many times. All this is extremely cumbersome, at least with Kindle (I did only try Google Books as an alternative but found almost no books I am interested in. Same by the way for movies (less than on a regular plane flight) which one cannot even rent in English).

The Kindle app does not have a central place to look through your notes or highlights (apparently in the US store there is "my Highlights and Notes"). It does not allow multiple page markers or general sidenotes like a quick pencil brush. It's, like the tablet, for grandma reading, not for working.

But even with longer novels it's not pleasure. There is only a very rough feeling of process as the bar and remaining time are based on tags (for chapters) apparently randomly distributed through the books I've read. The process bar shows a general process even if there is lots of advertising and errata in the book - which also destroys the nice experience of finishing a book. I had to scroll though some multiple times until the index showed 100%, a few will probably never make it over 99%. Reading multiple books in parallel (yes, I multitask) is annoying because they all show up, randomly ordered and no grouping.

In addition, you cannot rent or nicely give an E-Book present. A voucher for Christmas, really? Why can't I transfer it in virtual gift wrap? Why is there no way to transfer a read book with a nice personal ex-libris note? That probably put the final nail in the coffin.

Sorry slick technologies, at the moment you just annoy me.

Inspired by XCKD 1309



Saturday, 9 November 2013

Offline First

In temple architecture, the main room stands at a considerable distance from the garden; so dilute is the light there that no matter what the season, on fair days or cloudy, morning, midday, or evening, the pale, white glow scarcely varies. And the shadows at the interstices of the ribs seem strangely immobile, as if dust collected in the corners had become a part of the paper itself […] where dark and light are indistinguishable
Jun'ichirō Tanizaki, In Praise of Shadows, 1977

Hoodie.io, an awesome web app framework, started the “Offline First” initiative.

It struck me for two reasons: First, it’s the right way to go and I have been looking into Meteor or Rendr/Backbone for some time. In a world, where services converge across technologies, platforms and ecosystems, technology needs to go a similar way (see my W-Jax talk). Seconds, I was quite surprised the let’s-code-all-startups-in-javascript-scene is realizing that! I’ve had my troubles following all the JavaScript developments of recent years (with the exception of Node) because their use cases simply didn’t make too much sense for me, it all seemed to be exclusively fitted for kinda-social-cloud-powered-minimalistic-apps. Seeing this attitude changing makes me feel optimistic and encouraged.

Until recently, the web app world was like “The West” in Tanizaki’s book: Always perfect, brightly lit, accepting no natural error, resilience was only required in certain places like hardware. Tanizaki praises the shadow, and more the diffuse actually, as a juxtaposition to the always-bright, the efficient and the productive. In building resilient, adaptive, “Offline first” systems we now embrace the shadows, the connection problems, the version conflicts, the deadlocks. And more, we embrace the diffuse, the not-so-clear situations to be identified, auto-corrected or escalated to the user. This means we value adaptability over usability in some areas, giving the user control (if she wants or not) over the process. This means we have work closer with users, design better services, fail gracefully.

As an enterprise guy, where mobile applications have been in place for some time, my projects have always been “offline first”, i.e. “complex” rather than “complicated”. It’s the reason I looked into CouchDB for mobile sync. Even when I built applications mixed with WebViews and native views, this very distinction was made taking into consideration the connectivity context. Connectivity is a part of responsive, or adaptive, or reactive, design. And therefore a part of flow-oriented, resilient service systems that can adapt dynamically*. 

Or, as Ethan puts it, with a nice reference to How Buildings Learn and the aging process: “Shearing Layers”, which means acknowledging the gaps, designing for change where the system is exposed to natural forces and “invite our users into some of these problems” i.e. move conflict resolution to the user, and make visible the complexity - with a suggestion system at work.

Or, in Tanizaki’s words:
The quality that we call beauty […] must always grow from the realities of life, and our ancestors, forced to live in dark rooms, presently came to discover beauty in shadows

*) If you read my blog regularly you know I am not a fan of cybernetics the way Sussna is proposing it as an automated solution to cope with complexity. I like to quote Steve Jobs: “people don't know what they want until you show it to them”. However, I was happy Sussna did the JAX keynote, agreeing with him almost entirely, I fully agree to his Manifesto.


Monday, 21 October 2013

The application server is dead

Jonathan Harclerode and me gave the W-Jax 2012 Keynote, and have been giving it a few times since. Now, one year later, I'll write down the transcript in it's most recent version (for OpenSlava).

Sunday, 18 August 2013

Optimism vs. Pessimism

Recently I've read a nice maxim by Bill Clinton "Every person has an optimist and a pessimist side. The trick is to be optimist on bad days and pessimist on good days".

In the technology world, we still live up to the optimism of the 50ies, it's considered anti-innovative, even anti-social, when concerns are brought up - unless you directly describe how you solved them. This begins with interviewers looking for  10x, Ninja and Rockstar programmers, assuming agile processes will work more productive amongst superstars, born with success and hyper-productive. Or people argue resilience is a bunch of fault-tolerant servers and session state in a distributed database that will make sure transactional safety for us (we don't care how), or delegating it to a messaging system that will encapsulate flow from us (we don't care how), or a hardware load balancer that will normalize access (we don't care how). But it's not relying on superpowers that creates successul networked systems. Evolution has told us: it's communication, the best communicating group of the fittest will win.

We're only at the very beginning of understanding complexity and peer-to-peer-networks. The military has a long history in understanding complex networked systems involving humans and therefore error. Looking at the current discussion around drones the problem does not seem to be ultimately solved. For our systems to achieve a kind of "Byzantine fault tolerance" against infrastructure errors, we need a new approach to concurrency and consistency. Once we include business-critical processes in distributed systems, we need to make sure information is valid - in the eye of the beholder. Usually, transaction safety is considered ubiquitous, but we need systems more like MVCC, that gives one user the impression of consistency, yet allowing concurrent modifications in limited scope. True Resilience is about having the user chose between optimistic and pessimistic locking, and providing a relevant consistency context for the user, hyper-consistency if you want. In military, logistics is key. In the same way, having access to trusted, coherent, resources, is key in our distributed systems.