From Ebooks to Esites

Especially via our institution’s Yammer activity stream (private Twitter) I and several of my colleagues raise awareness of the evolution of ebooks with their serial information metaphor to what are becoming know as rich media ebooks amongst other names with their highly interactive model. Possibly one of the typical examples is the iPad-specific Inkling platform with about 100 textbook titles across a range of disciplines. Inkling retains the ‘book’ distribution model where the reader pays to download an electronic lump that contains all the rich media – text, images, audio, video, and interactive elements. Admittedly Inkling textbooks can be purchased in smaller chapter lumps.

Just a few days ago a colleague, Allan S, alerted us on Yammer about reactive documents:

Really interesting way of interacting with your web documents - "reactive documents" uses a JavaScript API to allow every word to become an 'explorable analysis'.

Allan pointed us to the Explorable Explanations project created by Bret Victor that allows authors to create reactive documents which take several steps towards genuine rich media ebooks. Try out the examples especially the one Allan liked, the digital filter.

However if you are a budding author of a rich media ebook your doubts might be raised with the need to use a ‘JavaScript API’. As well as a writer you also need some programming skills. Then you need to add skills in graphic design, audio-visual creation/editing and an understanding of user interaction and behaviour.

Going further you need to understand the hosting and deployment of web sites – the only sensible cross-platform technology currently available. After all you will want your reactive rich media content to evolve over time, won’t you? Web site technology allows your readers access to your rich media ebook on all ereader platforms not to mention the wide range of other reading devices such as smartphones, tablets, ultrabooks and desktops.

It is clear by now that your rich media ebook has become an interactive web site or esite. Since it is unlikely you will have the range of skills just listed your esite must be built by a multi-disciplinary team either assembled by you or your publisher. We might expect software developers to create suitable authoring tools eventually that will significantly ease the authorship process. Even so authors intending to join the rich media ebook movement should expect to bone up on their 21st century skills that includes some scripting/programming knowledge and a familiarity with new media creation.

Start thinking esites not ebooks. A corollary is to forget native apps unless they are backed by an esite and are generated automatically by your esite authoring tool.

Beta Testers Delight, an AWS EC2 AMI to Chew On

Not so long ago I was on the lowest rung of the Microsoft Partner ladder. Initially I received box loads of DVDs each quarter with the latest development and server software. Often it was several weeks after I needed the install disks, but I never used more than 10% of them. Then Microsoft moved to OTA distribution and I only needed to download those disk images that I actually needed, and I received them as soon as they were available. A big improvement except it tore a big hole in the Internet data cap.

This big distribution improvement did nothing for the next problem which was to find a physical or virtual machine on which to install and test the new software. But now even that chore has vanished. Joe Brockmeier reports on an ideal solution for beta testing new Microsoft servers in a post entitled ‘Amazon Spins Up Microsoft SQL Server 2012 on AWS for Testing’.

Amazon recently announced the availability of Windows Server 2008 R2 in its range of EC2 machine instances, AMIs. Now they have made available an AMI with SQL Server 2012 (Denali) community preview running on Windows Server. All beta testers need do is head to their AWS account and fire up the SQL Server 2012 AMI. In a few minutes they are testing the new version with no massive downloads, no local machine to find, and Internet data caps largely unaffected. Brilliant! Surely all new server software should now be made available this way.

Pity I am a Microsoft Partner no longer! I done ‘gone Google’ a year or so ago.

Code Snippet Archive to Benefit Everyone

I just saw a very useful jQuery code snippet from @aneesha in one of her tweets:

jquery to hide or show columns in a table $('td:nth-child(2)').toggle();

I don’t need this code today but probably could use in the future. Where should I store it for safe keeping? Indeed where should Aneesha store it for all software devs to use?

I have been storing such coding gems in my Evernote repository (great for me), and I can even make my Evernote notes available to everyone (only great if everyone can find them). This is not a good solution for a really useful repository and permanent curation.

However I did come across a much more useful solution when I attended the BrisJS meetup earlier this week. Pete Chappell gave a lightning talk about hashbangs and he put his notes/slides/code examples in the gist repository collection on github. As all developers have long known github has become the popular place to store shared, distributed repositories of code/data/text documents of all kinds.

You don’t have to be a software developer to find these repositories useful, they can be used for web sites, large structured documents, data collections and so on. git and github are supported on all hardware platforms.

github says of gist:

Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable [copied, cloned] and usable as a git repository.

You can create both public and private gists and update them to new versions as time goes by. All the public gists are searchable and there is an immense treasure trove of code and data samples there, both big and small. Pete Chappell’s gist is number 1,258,359 for example.

If you have text-based data of any kind you want to share publically or privately long-term then gists are for you. OK, Aneesha?

Writing Faster Programs about to be Harder and Harder

The computer-buying public have known for a year or two that individual central processing units or cores have ceased increasing in speed. The faster computers on the shelves need multiple cores. The same is becoming true for smartphones and tablets that now need multiple cores to be faster. But heed the warning from Steve Blackburn in his post on ‘Performance anxiety: the end of software’s free ride’. Writing software that runs faster from here on in is going to be very difficult indeed.

As Steve points out we have known how hard it is to write software to keep our multiple cores executing at the same time, ie parallel processing. He cites the simple example:

just as two cars are unlikely to get you to work faster than one, the addition of another core is often unhelpful in completing a computing problem more quickly

In the last 30 years of my computing experience the advances in writing parallel programs have been slight. So this is the first hard problem.

We used to think it was easier to make all the cores the same but it is now becoming clear we need a hierarchy of cores with varying power to control them efficiently – ‘ many designers now believe that we need a more complex combination of simple and powerful cores on each chip’. so ‘ heterogeneity takes us even further from the world of transparent performance improvements’.

Steve then reveals the problem of giving enough power to lots of cores on one chip. There is an obvious physical limit.

In practice, power densities on chip have become so high that we can no longer fully power an entire chip lest we melt the silicon. This radically changes the economics of microarchitecture.

Thus software developers must now optimise for energy consumption, not performance – a completely new approach will be needed. New optimisation algorithms will be needed.

The hard problem of parallelism still lies unsolved after decades. We computer scientists are going to have to do a lot better with the heterogeneity and energy optimisation hard problems if smartphone/tablet/laptop/desktop performance is not to stagnate. A dim prospect indeed unless some new lateral thinking can come to the rescue.