Yesterday on Hacker News, there was a thread about Wikidata, Wikimedia Foundation's new knowledge base. This comment struck me especially:

I was using Wikipedia the other day and it occurred to me how primitive it is to have all the inner links to other Wikipedia articles defined manually, surely these should have been automated by now (i.e., marking a word or two would link you to the relevant article).

And indeed, this is a usability problem that can already be fixed with the Semantic Interaction stack underneath Create.js.

Introducing Annotate.js

Annotate.js is a VIE widget built by Szaby Grünwald. It works very similarly to a spell checker in traditional text editors — you write text, and it highlights the potential entities you might want to link to. You then can either accept or decline these link suggestions by clicking them. In case of multiple potential matches, you can also disambiguate between them by selecting from an offered list.

Here is a quick video of Annotate.js in action:

You can also try it yourself with an online demo.

Currently Annotate.js has been integrated with the Hallo rich text editor, but it would be easy to do the same with other popular editors like Aloha and CKEditor.

Connecting to entities

The big question with automatic linking is where the entities come from. There are services like OpenCalais that can provide these suggestions for your content, but most of them are focused only on shared knowledge bases of big companies, famous people, and major cities.

Unless you're running a newspaper, it is unlikely that these are the things your content is about.

Apache Stanbol is an open source engine that can provide the enhancements for you. Out of the box it provides suggestions based on the Wikipedia knowledge repository. But more importantly, you can feed it with your own entities.

This way the enhancements you get for your content can be tuned to be meaningful to your content and your audience. If you write about medicine, they could be about symptoms and diseases, or if you're writing about technology, they could be specific open source projects and their contributors. With Stanbol, the choice is yours.

The current downside of Stanbol is that you'll have to run it yourself, but there may be solutions coming for that as well.

Beyond editing

Like never losing your content or managing collections, Annotate.js shows what we can do to improve the editing experience when we interact with it in a semantically meaningful manner.

What Annotate.js does is not merely creating links, but it also marking the machine-readable relationship between them and the HTML content being edited. This can then be used by yet another set of tools — like search engines — to understand and organize the content better.

It is easy to see Create.js (like Drupal did, unfortunately) as just an easy way to add nice inline editing features to your CMS. However, while that is a good initial step, the addition of being able to interact with your content on the semantic level can do a lot more. Automated linking is just another demonstration of that.

As the ecosystem around Create.js and VIE matures, and it ships in more systems, there will be things that we can't even imagine now built on the stack.

If your CMS is properly decoupled, you can benefit from that immediately.

What I've been doing

I would love to tell stories of working from parks and cafes, like Mark O'Connor has on his iPad setup, but unfortunately we had a backlash of winter here in Berlin and the warm spring weather only came back this week.

Instead — quite atypically — I've been mostly desk-bound in this time. The EU projects that mandated a lot of travel have now ended, and my current projects are more about software development than evangelism.

But that actually makes this experiment even more useful, as it means most of the six week has been actual programming, which is what most of my readers also do.

For those who missed my setup in the previous post, this is how it looks in action:

On-screen are tmux, vim, and a Grunt test automation watcher running inside a MOSH client.

Here are some things I've done in the last month:

• Porting the NoFlo flow-based programming engine to run in both browser and Node.js with the same codebase, including a tutorial on how others can do the same
• Writing and publishing an implementation of Android-style Action Bars for web apps
• Adding multiple major features to the web-based NoFlo IDE
• Dealing with the issues raised with the release of jQuery UI 1.10 and Backbone 1.0.0 with Create.js and VIE
• Blogging, including publishing some quite popular posts

In general the experience has been a positive and productive one. I'll write about some nuances here.

Web debugging

As you can see from the list above, much of my recent work has been client-side. With this, the unavailability of web debuggers on mobile browsers can become a problem.

I've tackled this issue in two ways:

• More tests. Instead of poking around in a debugger, I try to write Mocha tests for most aspects of my applications. This also has the benefit of automation, meaning that PhantomJS will test everything in my application every time I commit
• VNC and desktop browsers. When I really need one, I can still use the web debugging tools of traditional web browsers via VNC

See Mark O'Connor's setup instructions for VNC on one of these tablet workstation setups.

Post-PC means post-Office

One area where tablets are really lacking is support for traditional office tools like word processors and spreadsheets. There is a Google Drive client, but it is very slow (even small spreadsheets can take minutes to load) and mostly non-functional (word processor doesn't even support headlines).

There are also some other office suites available, but even these are better used for viewing documents than actually making changes to them.

But the bigger question is whether traditional office tools even have a place in this modern world. The commentary on constant delays with Microsoft Office for iOS and Android shows that people don't see them as that relevant any longer:

For the longest time, Office was the ubiquitous productivity suite. Everybody used it. Nobody considered using anything else. However, since this mobile revolution started, even non-geeks are starting to question whether Office is still all that. I had breakfast this morning with a CPA who does all of his work in Google docs. There is an entire generation of future workers going through high school and college now who don’t even have Office installed on their computers. If Microsoft has any hopes of keeping Office relevant, it needs to be everywhere, including the iPad.

Personally, I might be a lot better off writing my documents in Markdown, versioning them with git, and maybe using custom data-gathering applications with CouchDB map-reduces for data visualization.

The story of tablet productivity is still evolving. The new tools and interaction techniques we have will eventually give rise to new kinds of productivity applications. That may signal the end of the Office hegemony.

Presenting from the tablet

On the first week of this experiment I was actually traveling. The final review meetings for both of the EU projects were being held in Brussels and Luxembourg, and I had to present our results.

As the presentation tools on Android are not very good, I took this as an opportunity to finally start using an HTML-based presentation system. For this, I picked DZSlides, with a custom Jekyll-based flow for constructing slide decks from individual assets stored in git.

The results are quite nice, and I love being able to embed live demos inside the slides.

With every computing platform, there is always some fiddling involved with getting your device connected to a beamer. I was positively surprised with how easily the Nexus 10 worked. Simply connect using a micro-HDMI to VGA adapter, and you'll have the tablet screen up on the projector.

Minor annoyances

Everybody knows about the common gripes with Android on large tablets — most apps have been written with a narrow phone screen in mind, and simply look bad on a wide 10" screen. Twitter is a good example of the typical neglect of Android's UI guidelines.

Somewhat surprisingly, this even applies to Google's own tablet applications. Apps like Google+ and Google Drive are a lot more functional on an iPad than on a large Android tablet.

However, these are more of a problem when using something like my Nexus 10 as a media tablet, and don't really affect how well it works as a programming workstation.

For programming work, what matters is things like the beautiful screen, Android's reasonably good support for hardware keyboards, user-accessible file system, and the ability to share information between applications. These are the main reasons why I went with Android instead of an iPad.

However, not all is sunshine. So far, the main annoyances for me have been:

• Regressions in Magic Trackpad support mean that it is practically unusable when you also have a Bluetooth keyboard. A lot of character presses get duplicated, making typing near-impossible. I'm assuming other mouse devices would however work
• MOSH ConnectBot — which I'm using for my programming sessions — makes Ctrl and Esc keys not work. Luckily I was able to find a workaround
• Android 4.2.2 is buggy on the Nexus 10. Especially Chrome can cause the system to crash. Other browsers help here, and hopefully Google will fix the issue soon

Now, crashes and freezes may sound like a big deal. But thanks to using tmux, they just mean a short interruption, and not any lost work. I just restart my tablet or MOSH client, attach back to the tmux session I was working with, and I'm right back to where I was, cursor position, vim splits, and all.

Quantifying productivity

Calculating programming productivity is notoriusly difficult. While Mark was able to show impressive figures from his iPad setup, I don't have anything similar because:

• I haven't had the time to crunch the numbers on the work I do
• The ending of the EU projects meant that I'm now doing different things than I did with my laptop, and so comparing results from the two is hard

And in the end what matters more is the results of the work, not the effort spent getting there.

But still, it would be good to have a bit more data on how well the setup works besides the subjective "it feels like a good way to program".

To this end, I recently started using the RescueTime tracker on both of my Android devices. It keeps calculates how much time I spend with different applications each day, and even allows me to give some sort of productivity scores for them:

I'll be running this for a while, and will try to combine it with some statistics from my GitHub account. Those two should be able to paint a picture of how I work.

Conclusions

In the beginning, like with any new tool you have to start using, the Android tablet setup felt weird and limiting. But it has grown on me since, and right now I'm not regretting giving my laptop away.

But at the same time, if a new interesting device came out, the cost of switching to that would be minimal. After all, the Nexus 10 for me is essentially just a window into the web and my terminal running somewhere else.

In a way this decoupling is similar to the traditional desktop PC setup where you have a separate computer, screen, mouse, and a keyboard. The difference here is that none of those parts are bound to a desk or connected with cables. Instead, the peripherals talk with my screen over Bluetooth, and my screen with the "computer" over the Internet.

If I for instance want a better keyboard, I can just buy one and replace that part without having to change anything else with my setup.

Cost advantage

One aspect that people have remarked on is cost. Over the course of two years — which is the typical replacement cycle of a professional workstation — this setup is cheaper than a MacBook Air. And with that price I get a lot better screen and about double battery life, and even a smartphone.

What I lose is the ability to work fully offline, though somewhat alleviated by having local vim and git via Terminal IDE.

Moving forward

The experiment will keep continue. In these six weeks, I haven't seen any negative impact on my productivity from working on an Android tablet instead of a laptop, and many positive ones. Portability, battery life, and the emphasis on tests and automation are probably the foremost.

Of course, new devices come to the market, and eventually something will come that beats the current setup. But then I'll be able to switch without even losing my cursor position, so the only cost is the hardware itself.

In time, I will write more about how things are going.

Many of the building blocks are already in place, and so the port should be complete still this week. You can track the work in issue 63.

A fragmented ecosystem

The current client-side JavaScript ecosystem is quite fragmented. While on general level any code can be used anywhere, there are many different approaches at packaging, code loading, and templating. In many ways this resembles the PHP landscape before Composer solved the problem there.

On Node.js we haven't had this problem for a while, as NPM provides an excellent way to share and install code. With more than 27000 modules available, it is truly the default solution for JavaScript package management server-side. Some frameworks like Meteor tried to deviate from this by introducing their own package managers, but eventually came back to the fold.

Module definitions

There are many different ways for handling loading and encapsulation of JavaScript code. The module pattern is quite popular building block. Many also expose their code as jQuery plugins even though that really only makes sense or DOM handling.

Here is how you would define a jQuery plugin:

(function ($) {
  $.fn.somePlugin = function () {
    // some code here
  };
})(jQuery);

Some efforts towards standardization have been made, including the Asynchronous Module Definition spec, and the synchronous CommonJS module spec that Node.js also uses.

Here is how an AMD wrapper for code looks like:

define('somePlugin', ['jquery'], function ($) {
  return function () {
    // some code here
  };
});

The CommonJS definition for something similar would be the following. This will look familiar to Node.js developers:

var $ = require('jquery');
exports.someFunction = function () {
  // some code here
});

Harmony is the proposed next generation of the JavaScript language, and it includes a new module syntax:

module 'myModule' {
  import 'jquery' as $;
  export function someFunction () {
    // some code here
  }
}

It is no wonder many developers feel a bit lost on how they should expose their code or widgets!

The Harmony module spec may eventually harmonize this, but it will take a while before you can actually ship code like that for even a reasonably majority of browsers.

Module installation and loading

Once you've picked the module pattern to follow, the next question is how to actually get your dependencies installed.

The traditional way is to fetch "known good" versions of the libraries, add them to your project repository, and then just include each library with its own script tag. But this means having to maintain all the libraries in your own project, and cluttering your repository and change log with them.

A variant of this is loading common libraries from a Content Delivery Network like Google. This has the advantage that your users won't have to download something like jQuery separately from each web server, and that you don't need to duplicate the library files in your own code repository. But at the same time, this relies on the CDN provider not breaking things, and complicates offline usage.

And you still have to write script tag for each of them.

Bower

Twitter's Bower package manager aims to help with dependency management. You declare the libraries your code needs in a component.json file, run Bower, and you'll get the correct versions downloaded to your system.

Bower only handles dependency resolution and downloading, and so you'll still be writing script tags for all modules you installed. But at least this allows you to keep the library files out of your repository.

Require.js and volo

The Require.js project seeks to solve this by handling module loading for you in an automated manner. They even provide the volo package manager for installing all the libraries you need.

Require.js is a quite popular way of solving this, but means that you will need to follow the Asynchronous Module Definition specification with your code.

Component

Component is a newer solution for this started by TJ Holowaychuk of Express and Mocha fame.

The system is explained a lot better in the introductory blog post, but in nutshell Component is a combination of a package manager and a module loading system based on CommonJS.

With Component you can easily write and distribute reusable JavaScript modules, including user interface components that may include HTML templates and CSS. There is a component writing tutorial available.

The Component installer will pull all the dependencies for you, and construct a single, easy-to-include JavaScript file out of them and your own code. If you want to think of it in that way, this is sort of similar to Composer generating an autoload file for PHP code.

Which to choose?

Given the multitude of options available, it can be hard to choose which one to go with. Eventually a winner may emerge, but in the meanwhile, my approach is the following:

• Component for client-side libraries and widgets
• NPM for Node.js libraries

If I was just writing client-side code, Require.js and volo may have been just as good option, at least if I want to deal with AMD.

However, the big advantage of Component is that it is based on CommonJS modules, which Node.js also uses. With it, I can share library code a lot more easily between browser and the server, the two main platforms of the Universal Runtime.

CommonJS modules run nicely in the browser, on Node.js, and other server-side JavaScript runtimes.

Writing a multi-platform library

Writing widgets with Component is covered nicely in the building a date picker component tutorial, and so I'm focusing on how to build more general-purpose libraries here.

Getting Component

The first step with Component is getting the tooling in place. Component — like most of the JavaScript dependency managers — is written on top of Node.js. It would be possible to implement the Component spec in other languages for easier integration in their native toolchain, but for now Node.js is what you must install.

Once you have Node.js running, getting the Component tools is easy:

$ sudo npm install -g component

This will give you the component command. You can run it to see the functionality it provides.

Finding dependencies

The next step is to find the libraries you need. Quite a lot of libraries and widgets are already available, and can be found from the Component Wiki.

You can also use the Component command to look up modules:

$ component search underscore

component/underscore
url: https://github.com/component/underscore
desc: JavaScript's functional programming helper library.

nathan7/memoize
url: https://github.com/nathan7/memoize
desc: underscore's memoize

As you can see, the components use a "GitHub-like" naming scheme of <vendor>/<module>. This is again similar to vendor names in Composer:

The package name consists of a vendor name and the project's name. Often these will be identical - the vendor name just exists to prevent naming clashes. It allows two different people to create a library named json, which would then just be named igorw/json and seldaek/json.

Since NoFlo relies heavily on Node's event API, we need to find an equivalent library for Component. After a quick look through component search events, it turns out component/emitter does the job.

The component.json file

Each Component module must provide a component.json file where you declare things like the name of the package, the version number, the software license, the files provided, and the possible dependencies. This is quite similar to the package.json file in NPM.

I'm using a very simplified version of NoFlo's Graph class as the example here, so I can call the library bergie/graph. Like most JavaScript libraries, this will be under the MIT license.

{
  "name": "graph",
  "repo": "bergie/graph",
  "description": "Simple graph class",
  "license": "MIT",
  "version": "1.0.0",
  "scripts": [
    "graph.js"
  ],
  "dependencies": {
    "component/emitter": "*"
  }
}

For Node.js support you'll also need a corresponding package.json file:

{
  "name": "graph",
  "description": "Simple graph class",
  "main": "./graph.js",
  "version": "1.0.0"
}

Once the dependencies are declared, run the installation:

$ component install

The example only uses Node.js's built-in libraries, so NPM installation is not yet needed. If you add third-party libraries, you need to install them also:

$ npm install

Module code

Writing a Component module is very similar to writing Node.js modules. Create the file we just declared in the JSON file and open it in your favourite editor.

Since we're aiming for multi-platform code, the main difference is dealing with platform-specific differences. For example, the event emitter library in Node.js is called events, and the Component equivalent is called emitter.Luckily their APIs are exactly the same, so we only have to do loading conditionally:

var EventEmitter;
if (typeof process === 'object' && process.title === 'node') {
  // Node.js
  EventEmitter = require('events').EventEmitter;
} else {
  // Browser
  EventEmitter = require('emitter');
}

This way, we have the correct event emitter implementation available for our code. Now we just create a constructor function to inherit from that:

// The constructor, just call "super"
function Graph () {
  this.nodes = [];
  EventEmitter.call(this);
}

// Set up inheritance
Graph.prototype = Object.create(EventEmitter.prototype);

// Define methods
Graph.prototype.addNode = function (name) {
  this.nodes.push(name);
  this.emit('node', name);
};

Once the code is there, we need to expose it as a CommonJS module:

module.exports = Graph;

Running the module in Node.js

For Node, this is all we need to do to be able to use our Graph as a module:

// Include the module
var Graph = require('./graph');

// Instantiate
var g = new Graph();

// Hook into events
g.on('node', function (name) {
  console.log("Node added " + name);
});

// Call a method
g.addNode('Foo');

Running this should end up with message Node added Foo shown on the console.

Running the module in browser

To be able to run the module in the browser, we need to run Component's build process.

$ component build

This will generate a JavaScript file build/build.js which provides CommonJS module loading support, and all the JavaScript code we've declared in the JSON file.

Now you can include that file in your HTML, and start using the Graph module:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <script src="./build/build.js"></script>
    <script>
      var Graph = require('graph/graph.js');
      var g = new Graph();
      g.on('node', function (name) {
        alert("Node added " + name);
      });
      g.addNode('foo');
    </script>
  </head>
  <body>
  </body>
</html>

Conclusion

Component can be used for solving the JavaScript code-sharing problem. They let you build full applications out of smaller, reusable modules. And thanks to the CommonJS module specification, it is quite easy to write these modules in away which enables them to be used also under Node.js and other JavaScript runtimes.

This post, and the date picker tutorial should give you enough information needed for starting to decouple your front-end applications, and to participate in the emerging open source Component ecosystem.

Even with more than 800 components available, it is too early to declare Component the winner in the front-end dependency management space, but it is a well-designed system that works quite well.

I will be utilizing Component for some of my JavaScript projects in the future.

Many made the argument that the tablet was "just a big iPod Touch or iPhone":

at the end of the day, the show's centerpiece - the iPad -- is just a big iPod Touch. Lots of folks will want it, in a hypothetical sort of way. But it's hard to imagine all that many of them will fork over the initial $499 for a crippled version

The funny thing about this argument is that — while the skepticism was misplaced — the core point was true: The iPad is just a big iPhone.

Or to put it the other way, the iPhone is just a pocket-sized iPad.

Tablets of different sizes

There was a recent Time interview of the computer science legend Alan Kay. I shared it on Google+, and there was some discussion. I made the following argument:

In the end there are no phones any longer. Just tablets of different sizes, from tabletop (iPad, Surface) to pocketable (what we call smartphones)

The chances are that if you're reading this post, you will have what you consider a smartphone. Look at it, and consider how you use it. Is it really a phone, or is the way you use it a lot closer to what you'd consider a tablet?

Back in mid-to-late 2000s, we had Nokia's Internet Tablet devices. We considered them tablets, and did tablet-like things on them. The Nokia 770 tablet had a 4.13" screen. The iPhone has a 4" screen, and the Nexus 4 has a 4.7" screen. And yet somehow the first device was seen as a tablet, and the two latter as smartphones.

The software running on smartphones and tablets is nearly identical, as are the use cases.

Phablets meet in the middle

Smartphones and tablets are converging, quickly. Manufacturers know this, and the device-buying public is starting to see it too. But still the gadget blogs love to diss the large "phablet" devices, even though they sell quite well.

The problem here is that many technology bloggers still try to keep the two categories of devices — smartphones and tablets — separate, even though they really aren't. Maybe these devices are two big for holding against your head for a phone call, but who really does that anymore?

In reality all of them are tablets — windows on the web — and the only difference is that some of them fit in your pocket, and others need a bag, providing a bigger canvas to see information and work on in exchange.

This is the use case I have. For most of my internet and communication needs, I'm using a Nexus 4 as a pocketable tablet. I also have a larger tablet, which I use as my workstation and for some things where a bigger screen is nicer, like graphic novels.

Some are even able to do all their work on the smaller phablets.

End of telephony

The big news here is that the telephony part of a smartphone is not going to matter for much longer. Internet-based communication tools like instant messengers, email, and hangouts provide richer ways to interact, and don't tie you down to a specific device, or a specific telecommunications provider.

In the long run, this means an end to phone subscriptions. As I wrote on my "hacker's toolkit", buying prepaid data is cheaper and easier:

As the MiFi is only used for Internet access, I can buy cheap pre-paid SIMs from each country I travel to. Paying somewhere around ten euros for a month of Internet abroad certainly beats the usual roaming charges!

This is already happening. For example, Asymco reported on dropping SMS volumes in Spain:

After peaking at the end of 2008 at about €450/quarter, revenues have fallen by 60% to about €171 million in the third quarter of 2012. These figures represent almost 100% operating profit for operators so the impact is felt directly in the bottom line.

The culprit is IP-based messaging. Services like Whatsapp, iMessage and even Facebook offer “free” messaging to users who have a smartphone and a data plan. I’ve been told that 97% of Spanish smartphone users have Whatsapp installed. In some markets this “free” messaging is offered via BlackBerry Messaging.

This obviously is a development telecommunications companies are scared of. But while SMS and call volumes go down, the other change is that all these new devices will have SIM slots, and so the operators can sell a lot more of data plans.

Some of them are already targeting this new world. T-Mobile recently killed their traditional subscriptions and subsidies in favor of prepaid plans.

This is a new world

The computing world is switching to tablets rapidly. These tablets can be smaller or bigger depending on the requirements of the user, but they all are internet-connected, touch-capable and full of sensors. They already fit use cases from software development to watching media or social networking.

This will mean eventual changes in our culture:

My generation will be at something of a loss when this new world comes about. In my life, I’ve been rewarded for communicating effectively online via text. I’m a reasonably effective verbal communicator, but not nearly as good as I’ll need to be to compete with the telepresence-native adults that the children of today will grow up to be.

Today’s digital natives will be tomorrow’s telegraph operators. The only way to survive will be to understand the impact of pervasive video communication before it sweeps us under our keyboards.

PCs will still remain as the main productivity tool for some years, mainly thanks to all the legacy software built around that ecosystem. But the VisiCalc moment of tablets will come, sooner or later:

Every major shift in computing has brought its new big companies. PCs gave us Microsoft, web Google and Facebook. In the tablet space the focus has so far been on hardware and platforms, but I'm quite certain there will be winners in the productivity software space as well, companies that we may not have even heard of yet. Maybe your company is going to be one of them?

For now, I'm considering my adventures in the tablet productivity world an experiment. But day by day, my work tablet setup is feeling more and more comfortable.

Right now I don't miss my laptop. Or having a phone number.

When you learn PHP from WordPress as I (and probably many other people) did, you just assume that all the idiosyncrasies and illogicalities are par for the course when building a CMS-driven site. It’s taken me several years to realise that it doesn’t have to be like this. In fact, it wasn’t really until I started learning more about OO principles and working with frameworks that I started looking at WP in a different light. Why is every instance of every model treated like a post? Why can’t I extend the functionality of a post type without writing a whole mess of hooks, filters and functional code into a file that isn’t semantically related to that post in any way?

These may sound like the gripes of someone whose needs will never be met by something like WordPress, but the lack of fundamental logic that gives rise to the above issues is what makes WordPress problematic for developers at all levels. And because the crossover on the venn diagram of ‘people who know good application development practises’ and ‘people who build sites in WordPress’ is such a thin sliver, it just trundles along in its current hokey state, baffling both the unseasoned and the proficient developer alike.

As expected, this generated a lively discussion on Hacker News.

Technical debt

Now, I've used WordPress on-and-off ever since it was still called b2 cafelog, but I wouldn't consider myself a WordPress developer. But still, looking at it mostly from the outside, it is clear that many of the issues WordPress users and developers face today result from technical debt accruing from bad architectural decisions done a decade ago, and the missing will to correct those.

WordPress is still undergoing a transition from a blogging platform to a general-purpose CMS. The changes this requires mean that without a sound architecture, the problems with the underlaying engine will only become exacerbated.

This is not something unique to WordPress. Many popular CMSs, including Drupal and TYPO3 have been suffering from the same problem. We all in the open source CMS community have been there. The difference however is that these projects have identified this issue, and have taken steps to correct it.

Start decoupling

The reason why CMSs become so messy is because they all try to be so many things at once. A CMS is a web framework, a CMS is a web editing tool, and a CMS is a content store. But each of these are in reality their own, specialized areas, and so the principle of separation of concerns tells us that they should be handled by separate pieces of software.

I wrote a still-popular post titled Decoupling Content Management two years ago to argue just that. Projects like PHPCR and Create.js have since then sprung up to move that from idea to practice, and have already been adopted by many CMSs.

In nutshell, the transition I want CMSs — WordPress included — to make is this:

Here is my talk on the subject from JS.everywhere in Paris late last year:

We also talk about the cross-CMS collaboration this enables in the TYPO3 Neos launch video.

Think about it, developers from Midgard CMS and TYPO3 working together and sharing substantial parts of the user interface codebase, while still enabling each project to retain a unique look-and-feel!

Non-participation

Over the past two years I've given tens of talks about Decoupled Content Management in various developer and CMS conferences. In these events I've talked with a lot of developers from various different CMSs from both the open source and proprietary worlds. But despite its popularity, WordPress core developers have been absent.

Symfony activist Lukas Smith has noticed the same:

I think the first step would be that the WordPress core developers start to mingle with the PHP community. I simply have not met a single WordPress core developer at any PHP conference and I tend to go to 6-10 a year in various countries around the world.

I have also not seen any WordPress core dev participate on an php-src internals discussion let alone something like the Framework Interoperability Group that outs out the PSRs.

But without communication the chances of collaboration are low and without collaboration imho its going to be hard for WordPress to identify and assess the potential for new directions.

Moving forward

While WordPress is still the top dog of the CMS world, it is a precarious position that shouldn't lull them into complacency. The web moves forward, things change, and all technical debt must be paid eventually. And that is what can fatally slow down a project.

Solving the architectural issues is a big amount of work, and so I would start by examining how other projects like Drupal have made their transition. The part Symfony components to the rescue of your PHP projects of my Symfony Live Paris liveblog is a good place to start.

For WordPress, like for any PHP content management system, my secret agenda for PHP CMSs should apply. If you're a WordPress core developer, I'd love to chat about how to move forward.

The privacy scare

Much of the Glass marketing focuses on the camera aspect, as does the criticism and fearmongering around it. Some feel that the device would bring about an era of ubiquitous surveillance and loss of privacy. Some even label these people as Luddites:

StopTheCyborgs and other Neo-Luddite groups make some pretty compelling arguments against AR, including the credible threat that people could be recorded at any time without their knowledge or permission. Nobody could ever consider conversation in the presence of Google Glass wearers completely private. Any entity that could tap into and process all the information from Google Glass on a minute-to-minute basis could track anyone or any conversation anywhere near the wearers. Google Glass may well begin the destruction of our current definitions of privacy.

The mislabeling aside (the historical Luddites were more concerned about machinery taking away their jobs, as they and globalization together eventually did), the criticism is generally baseless.

We live in cities filled with thousands of surveillance cameras monitoring our every move. We pay for our groceries with credit cards that leave a mark on everything you bought — when, and where — into a database. We carry smartphones that are constantly reporting their location back to the operator. We post our private pictures and current activities to social networks. There is very little privacy left. If you'd see how detailed information law enforcement can get out of our every movement from your operator, you'd know that too.

In a world where a hidden, pencil-shaped spy camera can be bought for about 30$, is a very obviously visible Google Glass device really the biggest risk to privacy? And yet, places are banning them already, a lot before they actually hit the market.

This is the future

The anti-Glass movement has a benefit. While not exactly a flying car, it is yet another sign that we're living in the future that science fiction authors envisioned. I mean, consider the fact that there is A movement to ban cyborgs.

They even sell stickers.

Consider the possibilities

Since the privacy battle is already lost, shouldn't we instead focus on the possibilities they can bring? While Google has shown very little of the capabilities of the Glass software apart from videoconferencing and making web searches, various books can provide clues.

Many of them describe a world where you can share with anybody what you see with your own eyes, or access any information without having to hold a bulky device.

It is a little hard to provide good context of the use cases from the books just by short snippets, but here are some. Feel free to provide your own in the comments.

In Daniel Suarez's Daemon series, Glass-like devices are used for connecting and coordinating a full economy, called the Darknet. Here is a view of an office with augmented reality displays and motion controls:

The center of the room looked to be a staging area, bustling with your people, all wearing eyewear and gloves. To the side was a raised platformn lined with office chairs where a dozen people were grabbing, pulling, and pushing at invisible objects in the air. They were all speaking to unseen people, as though it were a call center.

I could easily imagine manipulating my flow based programs in this way.

The Daemon series also feature other Google products, like driverless cars and an augmented reality game much like Ingress.

Vernor Vinge's Rainbows End has everybody using augmented reality glasses as an everyday matter. They even change how you see a city like Barcelona:

Vaz strolled to the stone barrier and looked down. If he blocked out all the tourism fantasy [augmented by the Glass], he could see the freight harbor almost two hundred meters below and a kilometer away. The place was an immensity of freight containers rambling this way and that, chaos. If he invoked his government powers, he could see the flow of carge, even see the security certificates...

And of course people interact with the augmented reality projections of others just like they were present:

Even when her friends were gone physically, they were often still around, invisible presences [without the Glass] like Robert's doctors. Miri walked around the backyard talking and arguing with nobody—a parody of all the cellphone discourtesy that Robert remembered

For the less pleasant view of something like Glass, Neal Stephenson's Snow Crash focuses on the surveillance aspects, with people using AR displays being called Gargoyles:

Gargoyles are no fun to talk to. They never finish a sentence. They are adrift in a laser-drawn world, scanning retinas in all directions, doing background checks on everyone within a thousand yards, seeing everything in visual light, infrared, millimeter-wave radar, and ultrasound all at once. You think they’re talking to you, but they’re actually poring over the credit record of some stranger on the other side of the room, or identifying the make and model of airplanes flying overhead.

Then again, talking with a Facebook addict can already be a lot like that.

How this will play out

If the glass does what people want it to do, it will become popular.

Just like we've taken smartphones and tablets into our lives and homes, eventually we will live in a world where you will feel naked if you step out of your home door without the glass on. How am I supposed to connect and communicate now?

I'd love to have Glass, even if it is clunky in the beginning.

Wearable computing is one of the possible trajectories we're going with, from room-sized mainframes to desk-bound personal computers to these amazing small slabs of glass and antennas we now carry in our pockets.

Just like with smart spaces, or tablets many years ago, I'm keen to explore the new interaction possibilities.

The safe bet would've been to just get a newer version of the Air, or maybe the 13" Retina MacBook with its great screen. A fresher approach would be a ChromeBook, either the cheap and light ARM ChromeBook, or the Pixel with awesome screen and design but crappy battery life.

I'm spending most of my days developing software, and so I should be able to work with a ChromeBook and a remote Linux box. But if that works, why not try working on a tablet? They're cheap, light, durable, and have an all-day battery life. And if Mark O'Connor was able to work productively a whole year with one, why couldn't I?

Since I already had a Nexus 10, this is what I decided to try.

The setup

The Nexus tablet has a great, "better than retina" screen, which can render my coding sessions and web user interfaces beautifully. The 10" screen is somewhat smaller than what I had on my Air, but not terribly so.

However, the big problem with tablet productivity is text input. Much of our current work environment is still textual, and typing on a non-haptic glass touch-screen is simply not very nice.

Hardware keyboard

To fix this I purchased a Microsoft Wedge Keyboard, which connects to the tablet over Bluetooth. Recent Android versions have quite full support for external keyboards, allowing me to use it for all text entry, and even for some keyboard navigation. So yes, Alt-Tab works.

The Wedge keyboard is about the same size as typical keyboards on compact laptops. Microsoft has always made good hardware, and the keyboard is no exception, providing a quite nice feel for the size it has. A handy additional feature is the included cover, which puts the keyboard to sleep automatically, and can act as a tablet stand when opened. No more issues with keyboard waking up in your bag and deleting everything.

For those prepared to lug a heavier option, there is a Bluetooth mechanical keyboard, which is probably a lot better than any laptop keyboard on the market. And if you already have a good keyboard, Android supports most of the USB ones via an OTG cable.

Desk setup

While I'm spending quite a lot of my time on the road, living out of my backpack, I do have a regular desk in the Berlin office I share with Content Control. Since my coding sessions are often long, I've been a bit concerned with my programming ergonomics for a while now, even considering a standing desk.

Tablet has the same advantage as a traditional display in that it is decoupled from the input devices, giving you greater freedom in how to position them. I have a Callstel tablet stand that allows me to place the tablet in practically any place and height above my desk. The current setup is just slightly below my eye height in the normal sitting position, but I'm still experimenting with that.

Gorilla arms

The Gorilla arm syndrome is what everybody brings up with every touchscreen computer — it is simply not nice to constantly lift your arm to touch the screen.

In my experience this isn't so much of an issue when you're using the tablet positioned similarly as a laptop screen would. But when the screen is up in a more ergonomic position, like it is on my desk, then this quickly becomes an issue.

To solve this I bought a Apple Magic Trackpad, which connects to the tablet again via Bluetooth, and allows both regular mouse usage with Android, as well as many multitouch gestures.

Why Android

Most people experimenting with replacing computers with tablets go with an iPad, the established market leader. iPad has many benefits over the Nexus 10, including a more mature software ecosystem, and better availability — if you break or lose your tablet, you'll be able to pick up a new one from practically anywhere, whereas the Nexus devices are only available online.

The reasons for me to go with Android have to do with openness. Since the core operating system is open source, there are custom ROMs I could use if I wanted, and I can do file management the traditional way when I need to. An even bigger reason is that the sharing system makes it possible to connect various applications together. Being able to run multiple broser engines is also nice for a web developer.

Another bonus is the availability of NFC on the tablet. I'm quite often sharing content between it and my smartphone. If I run into an interesting web article, I can either send it to my Kindle to read later, or touch the tablet with my phone and read the article on that. This is surely a feature that will gain more mindshare whenever it is introduced to iPhones.

I also prefer the rugged, rubberized look-and-feel of the Nexus 10 to the cold metallic iPad, even though a 4:3 screen would be better than the widescreen I have now.

Software used

I really don't need much for my daily work — just a browser and a terminal. Here are the apps I use on a daily basis:

• Chrome and Firefox web browsers
• JuiceSSH SSH client to access my remote Linux server
• TapChat IRC client
• File Manager HD for moving stuff around, including between file servers
• DroidEdit Pro for quick local file edits

In addition I'm using some of the built-in Google apps, like Google Talk, GMail, and Google+ for Hangouts.

For offline development I have an installation of Terminal IDE that allows me to run Linux utilities like vim and git locally. If I would root my tablet I could also install a Ubuntu chroot and run whatever I need. With a previous tablet I even was able to run Node.js servers and databases on the thing!

My development virtual machine is from DigitalOcean's Amsterdam site, providing quite nice fast connections here in Europe. I mostly work on it via tmux and vim, and run whatever processes I need, including long-running NoFlo flows.

Pros and cons

Based on my initial experiences of working with this setup for a week, working on a tablet is quite different from a traditional computer. Here are some good things:

• Battery life: the Nexus can easily get me through a full workday with a single charge, meaning that I only need to connect it to a wall overnight. It also charges via standard micro-USB meaning that I don't need any extra power bricks with me
• Portability: most tablets are smaller and lighter than full laptops. And they can be used more easily when standing, sitting on the couch, etc.
• Instant on: there is no suspend/resume cycle. I press the power button, the tablet recognizes my face via the camera, and I'm instantly back to where I left off
• Modularity: with a tablet, my work environment is built out of multiple modular pieces that I can take with me, or leave at the office depending what I intend to do. And I can set them up in different configurations when working
• Touch: for software developers, working on a tablet really drives home the importance of touchscreen friendliness. I've already noticed this affecting my UI designs
• Focus: everything is full screen, meaning no need for window management. Tablet software also tends to be simpler and has less configuration to fiddle with

But obviously there are some downsides as well:

• Office documents: the office suites available for Android are quite poor, and the mobile version of Google Docs is simply terrible. One solution would be using MS Office or LibreOffice over a VNC connection
• Mobile-first web: quite a few websites try to offer even large tablets like the Nexus 10 their silly mobile sites. Thankfully this is becoming less prevalent due to media queries and responsive design
• Offline: much of my current tablet workflow requires me to be online. I could write code and blog posts offline with tools like Terminal IDE, but there would be no way to run and test software
• Bugs: many tablet applications are still in their first generation and lack the maturity and robustness that their desktop counterparts have had time to gain
• Web debugging: while WEINRE sort of helps here, it is still a lot less convenient than the web development tools that come with desktop browsers

Conclusion

This tablet work setup is for now an experiment. If I find it hindering my productivity, I'll just have to get one of the laptops mentioned in the beginning of this post and work in more traditional manner. But if it works, then great! In that case I have finally found a more modern setup for programming work — one that gives me both better ergonomics and mobility.

I will try this setup for some period of time, and then report the results here on my blog.

The idea here is to facilitate collaboration and smoother project communications through various different tools that I'll describe below. While this already does a lot, it is obviously only the first step on the path to making offices smarter.

Office presence

An important part of collaboration is to know who is where. Maybe some people are having a lunch break, or are working remotely? The Office Presence Display system knows these things, thanks to various sensors:

• Bluetooth sensors can see smartphones and other mobile devices in the space
• WiFi sensor can see what computers are connected
• Google Talk sensor knows who are connected and active on their work accounts

With these, we know pretty well when you arrive to the office, and when you leave. Thanks to the sensor watching the company instant messaging system, we also know when people working remotely are available.

In addition to letting people know where the other members of the team are, this system can help with the perpetual annoyance in many companies: having to fill timesheets. We have a logger process that listens to the sensors, and logs the data into a CouchDB database. From there you can easily visualize working hours and availability trends:

In many situations it is of course not enough to know whether people are present, but also to know what they're working on. The next component of the system helps with that.

Electronic Kanban wall

Instead of the clumsy waterfall style, more and more companies are managing their projects in tight, recurring iterations. A Kanban wall is a great way to keep track of tasks as they move through the process, and to see who is doing what, and what could be possible to do next. The One day in Kanban Land post explains the concept well.

If everybody working on a project sits in the same room, and that room is also where all decisions about the project are made, then the traditional solution of whiteboards and Post-It notes is probably the best way to visualize Kanban. But for distributed teams and more flexible work, an electronic version is a lot better option. This way everybody can see the Kanban wall in its current state from their computer, a TV in an office room, or a tablet.

Our Kanban wall implementation provides exactly that. The same wall (or, in case of multiple projects or teams, a set of walls) is available through any web browser. You can also display it on a big screen in an office or a meeting room, and control that screen with the Kinect Air Cursor.

Now, for most companies this is not meant to be the master database of projects and tasks, but instead just to be an alternative view and controlling tool to wherever your project information resides. Maybe you're already using Pivotal Tracker, Basecamp, or OpenPSA? The Kanban wall server has a full REST API available, and so it is easy to integrate with any existing system. If a task is moved on the Kanban wall, it can be updated to the project tracking system, and vice versa.

If you're using both systems, then the Kanban wall is also aware of the presence information. We show a differently colored border around the "person tokens" depending on the availability state. You can also set different Work-in-Progress limits for different people and states.

Interested yet?

So far we've only trialed the system in our own office, but are now looking for some pilot customers to try the system out. If you're interested in making your workplace smarter, get in touch.

For those who like to tinker with these things, all the sensor software is available as open source at http://github.com/nemein.

Now, people have very different styles of traveling. Some plan everything in advance, and pack for every possible contingency. But not me.

Over the years I've built a style of traveling that involves very minimal planning and late arrangements. This can fire back — making flights or trains more costly, but it is still often worth it through the added flexibility. Maybe there is a meeting or a conference that pops up at the last moment, and can be combined with the trip with minimal detours?

An important component of that is to have travel gear that gives you the needed flexibility. For me this means a largish backpack that can carry all the work gear I need, and also fit about a week's worth of clothes and other things I need on daily basis. No need to wonder what extra to pack when the space is limited, and no need to check in luggage when flying.

And even more importantly, having a light and easy to carry bag so that you can just keep it with you for a day out in the city instead of having to first visit the hotel to drop it.

My current backpack is a Haglöfs Connect 17" that I got last Christmas. Prior to that, I was traveling with another backpack that I originally acquired for the long walk to Santiago de Compostela. That backpack was great for anything from daily commute to month-long trips around Europe, but was starting to be quite beaten up.

The new one is slightly smaller, more stylish, and most importantly, organized better. Now, for instance, I have a separate compartment just for my computer and its accessories. This makes airport security a lot smoother than trying to dig the computer up from behind clothes and other random things before putting it on the tray.

To keep the bag organized, I have an Eagle Creek packing cube to keep my clothes together, and occasionally one of their shirt folders whenever more businessy attire is required. I also have two toiletry bags, one of the actual toiletries and the other for cables and whatever adapters I need to connect when giving presentations.

One week's worth of clothes can sound like too little, given that often the trips can be longer than that. The solution for this is to use either laundromats, or, in a pinch, to pay for hotel laundy service.

All you need for travel is a good backpack. The Pack Lite blog shows other examples of packing lite for both work and holiday travel.

In nutshell, flow-based programming (FBP) is a paradigm where programs are built from components that have a set of defined input and output ports. These ports are then wired together to make a graph that defines the logic and the data flow.

Where we are now

At the moment there are two user interfaces that can be used for defining NoFlo graphs visually. DrawFBP is a desktop application that can define flow-based program graphs for both NoFlo and the Java and C# flow runtimes.

This is the most functionally-complete FBP user interface, but is somewhat limited by Java's cross-desktop capabilities and the inability to introspect the information available via NoFlo's component loading interface. In any case, it is a great place to start exploring NoFlo development visually:

I've been working on a web-based user interface purpose-built for NoFlo called noflo-ui. Here input ports are on the left, and output ports on the right. Boxes depict ArrayPorts:

The noflo-ui interface benefits from being able to talk directly to NoFlo itself, and so getting all the metadata about components and their ports. The current iteration was built with the jsPlumb library, and works also on touchscreen devices. Imagine programming your NoFlo graphs on a tablet!

Visualizing written flows

While the user interface is missing, the typical way to visualize NoFlo graphs is using the .fbp domain-specific language. In that, the graph shown in the screenshots above would be written as:

# Read a file
'package.json' -> IN Read(ReadFile)
# Split the file contents by newlines
Read() OUT -> IN Split(SplitStr)
# Count the packets
Split() OUT -> IN Count(Counter)
# Send the total count to display
Count() COUNT -> IN Display(Output)

# Display also file read errors
Read() ERROR -> IN Display()

The noflo-graphviz tool can be used for generating visual graphs out of this syntax:

While in the real world you'd probably want to edit the graphs visually, at least the graphviz tool can be useful for autogenerating documentation for larger flow-based programs.

Potential collaboration

Flow-based programming is not a new idea, and there are many other implementations available, from programming languages like Go to purely browser-based environments. The dataflow library aims to provide a common web-based toolkit for managing flows in any FBP environment:

When the library matures a bit more, it is likely to be the basis for NoFlo's graph editing interface.

Inspiration

The key part of making a user interface for NoFlo should be to make flow-based programs easier to make and to understand. As described in Bret Victor's great Inviting on Principle talk, development tools could do a lot more to make the flow of the software and the different options and settings understandable:

Flow-based programming tools can help a lot here, as the main logic of a program is anyway depicted as a visual graph.

With NoFlo we can even connect the user interface to a already running piece of software, allowing users to see what is going on and to make changes while the application is runs. Think of the mimic boards in nuclear power plants where the operators can constantly see the status of every part of the process.

Visual identity

We're building something new and exciting with NoFlo here, and so the visual identity should also reflect that. No need to follow the drab look-and-feel of traditional IDEs!

Consider this line from Tron: Legacy:

The grid. A digital frontier. I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then one day...

There is certainly something of flow-based programming right there. And this is why the current NoFlo UI has a distinct Tron-like look to it.

Another approach would be more organic, from how Alan Kay described object-oriented programming:

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages

The honeycomb flow graph on the Spree API documentation also looks cool:

Prior art

Yahoo! Pipes is what most people bring up when I describe flow-based programming. They have a quite nice web-based UI:

Apple's Quartz Composer is a very slick implementation of the same concept, but for the desktop:

If Apple made a finger-friendly version of this for the iPad, we would be pretty close to the UI NoFlo needs to have.

The big picture

A problem with most of the existing flow-based editors is that they go into too much detail, making bigger graphs hard to decipher. Of course, moving chunks of a graph to subgraphs and using those as components helps, but still a complex program can be a confusing tangle of crisscrossing lines.

Luckily, there is an area of information design which has tackled this problem already: transit maps.

If you consider the transportation system of a big city as a flow-based program, it consists of a huge number of nodes and connections. And yet it is easy for people to figure out how to get around. Just look at this part of the Berlin subway map:

The different tariff zones even map quite nicely to the idea of subgraphs in FBP.

There are some key points here:

• Don't focus on the details too much. You have nodes, and connections between them. Why show the port names on this level?
• Use color. Different flows in your program could be depicted as their own "subway lines"
• Nodes that are only connected to a single flow (for example, filters and converters) can be minimized, and more focus given to nodes where different flows interspect

NoFlo 0.3.1 will make it possible to annotate connections in a flow with arbitrary "route names" that can then be assigned to colors for visualization purposes.

Quite some research and tools already exist for automatic generation of subway maps. Maybe some of these could be repurposed to give the NoFlo UI a "bird's eye view" to your flow-based programs?

Moving forward

So, how to make this user interface happen? As mentioned, I'm building software with NoFlo on daily basis now, and so better tooling is certainly urgent. And not just for me, but for all the others interested in flow-based programming. In the recent project planning sessions I've allocated some time to this, and so I hope we can get somewhere with a more-or-less working user interface still during this winter.

There are many things to consider:

• Graph editing on both desktop computers and tablets
• Collaborative editing between multiple users, maybe via ShareJS
• Refactoring: moving parts of a graph to its own subgraph, or "blowing up" a subgraph back into the main graph
• Browsing the available components and graphs
• Seeing compatible port types when making a connection
• Writing new components and modifying existing, maybe with CodeMirror
• Running the NoFlo graph and seeing the packets passing through the different parts

All of this will obviously take a lot of time, but we'll have to see how far we get with the first iteration. Having an editor that people find more usable than writing graphs by hand should be the first goal.

If you're interested in this, please follow the noflo-ui and dataflow repositories. The Flow-based programming mailing list is also a great place to discuss your ideas.

You can take a look at examples or tests. The latter use Midgard content repository as a base.

Seminaarin tarkempi ohjelma sekä ilmoittautuminen osoitteesta http://nemein.com/aamiaisseminaari. Toivomme saavamme ennakkoilmoittautumiset 30.3 mennessä.

Tänä vuonna Nemein on lahjoittanut joulukortteihin tarkoitetut varat Suomen Punaisen Ristin  Katastrofirahastoon.

http://lanyrd.com/2011/helsinkijs-december/

Deloitten lista

The part of project's readme summarizes it well:

By using GICR APIs, a GObject-based application can use the standard interfaces for nodes, tree management, versioning and structured queries regardless of how the data is actually stored.

There's gicr-midgard2 which is first and initial implementation of GICR.

Simple examples demonstrate easy of use:

Initialize repository:

Repository repository = get_repository ();

Create new session:

var credentials = new SimpleCredentials ("admin", "password");
Session session = repository.login (credentials, null);

From external xml file, import data to repository

session.import_xml ("/", Environment.get_current_dir () + "/import_example.xml", 0);

Persist data

session.save ();

You can create new session for the same repository

Session readSession = repository.login (null, null);

And get stored node by its path

GICR.Node exampleNode = readSession.get_node ("/tests_general_base/idExample");

And finally, read node's properties

stdout.printf ("Node type '%s' created at '%s' \n",
    exampleNode.get_node_property ("jcr:primaryType").get_string (),
    exampleNode.get_node_property ("jcr:created").get_string ()
);