Category Archives: Software

Bugs, faults, and writing

Kindle Cover - Half Sick of Shadows
Kindle Cover – Half Sick of Shadows

Today’s blog looks at bugs – the little things in a system that can go so very wrong. But before that – and entirely unrelated – I should mention that Half Sick of Shadows is now available in paperback form as well as Kindle. You can find the paperback at Amazon UK link, Amazon US link, and every other Amazon worldwide site you favour. So whichever format you prefer, it’s there for you.

So, bugs. In my day job I have to constantly think about what can go wrong with a system, in both small and large ways. No software developer starts out intending to write a bug – they appear, as if by magic, in systems that had been considered thoroughly planned out and implemented. This is just as true of hacking software, viruses and the like, as it is of what you might call positively motivated programs. It’s ironic really – snippets of code designed to take advantage of flaws in regular software are themselves traced and blocked because of their own flaws.

Cover - I, Robot (Goodreads)
Cover – I, Robot (Goodreads)

But back to the practice of QA – finding the problems and faults in a system thought to be correct. You could liken it, without too much of a stretch, to the process of writing. Authors take a situation, or a relationship, or a society, and find the unexpected weak points in it. Isaac Asimov was particularly adept at doing this in his I, Robot series of stories. At the outset he postulated three simple guidelines which all his robots had to follow – guidelines which rapidly caught on with much wider audiences as the “Three Laws of Robotics”. These three laws seemed entirely foolproof, but proved themselves to be a fertile ground for storytelling as he came up with one logical contradiction after another!

But it’s not just in coding software that bugs appear. Wagon wheels used to fall off axles, and I am told that the root cause was that the design was simply not very good. Road layouts change, and end up causing more delays than they resolve. Mugs and jugs spill drink as you try to pour, despite tens of thousands of years of practice making them. And I guess we have all come across “Friday afternoon” cars, tools, cooking pans and so on.

1947 bug found and taped to the engineering logbook (Wikipedia)
1947 bug found and taped to the engineering logbook (Wikipedia)

Bugs can be introduced in lots of places. Somebody thinks they’ve thought up a cool design, but they didn’t consider several important features. Somebody thinks they’ve adequately explained how to turn a design into a real thing, but their explanation is missing a vital step or two – how many of us have foundered upon this while assembling flat-pack furniture? Somebody reads a perfectly clear explanation, but skips over bits which they think they don’t need. Somebody doesn’t quite have the right tool, or the right level of skill, and ploughs on with whatever they have. Somebody realises that a rare combination of factors – what we call an edge case, or corner case – has not been covered in the design, and makes a guess how it should be tackled rather than going back to the designer. Somebody adds a new feature, but in doing so breaks existing functionality which used to work. Somebody makes a commercial decision to release a product before it’s actually ready (as a techie, I find this one particularly frustrating!)

And then you get to actual users. So many systems would work really well if it wasn’t for end-users! People will insist on using the gadget in ways that were never anticipated, or trying out combinations of things that were never thought about. A feature originally intended for use in one way gets pressed into service for something entirely different. People don’t provide input data in the way they’re supposed to, or they don’t stick to the guidelines about how the system is intended to work – and very few of us read the guidelines in the first place!

Timing Kindle cover
Timing Kindle cover

All of which have direct analogies in writing. Some of my books are indeed focused on software, and in particular the murky business of exploiting software for purposes of fraud. That world is full of flaws and failures, of the misuse of systems in both accidental and deliberate ways. But any book – past, present or future – is much the same. A historical novel might explore how a battle is lost because of miscommunication, human failings, or simply bad timing. Poor judgement leads to stories in any age. Friction in human relationships is a perennial field of study. So the two worlds I move in, of working life and leisure, are not really so far apart.

Now, engineering systems, including software engineering – have codes and guidelines intended to identify bugs at an early stage, before they get into the real world of users. The more critical the system, the more stringent the testing. If you write a mobile phone game, the testing threshold is very low! If you write software that controls an aircraft in flight, you have to satisfy all kinds of regulatory tests to show that your product is fit for purpose. But it’s a fair bet that any system at all has bugs in it, just waiting to pop out at an inopportune moment.

As regards writing, you could liken editing to the process of QA. The editor aims to spot slips in the writing – whether simply spelling and grammar, or else more subtle issues of style or viewpoint – and highlight them before the book reaches the general public. We all know that editing varies hugely, whoever carries it out. A friend of mine has recently been disappointed by the poor quality of editing by a professional firm – they didn’t find anywhere near all the bugs that were present, and seem to have introduced a few of their own in the process. But just as no software system can honestly claim to be bug-free, I dare say that no book is entirely without flaw of one kind or another.

Cumbrian voice skills and Martian course corrections

Grasmere Lake
Grasmere Lake

My first piece of news today is by way of celebration that I have been getting some Alexa voice skills active on the Amazon store. These can now be enabled on any of Amazon’s Alexa-enabled devices, such as the Dot or Echo. One of these skills has to do with The Review blog, in that it will list out and read the opening lines of the last few posts there (along with a couple of other blogs I’m involved with). So if you’re interested in a new way to access blogs, and you’ve got a suitable piece of equipment, browse along to the Alexa skills page and check out “Blog Reader“. I’ll be adding other blogs as time goes by.

Cumbria Events Logo
Cumbria Events Logo

The second publicly available skill so far relates to my geographical love for England’s Lake District. Called “Cumbria Events“, this skill identifies upcoming events from the Visit Cumbria web site, and will read them out for the interested user. You can expect other skills to do with both writing and Cumbria to appear in time as I put them together. It’s a pity that Alexa can’t be persuaded to use a Cumbrian accent, but to date that is just not possible. Also, the skills are not yet available on the Amazon US site, so far as I know, but that should change before too long.

Amazon Dot - Active
Amazon Dot – Active

In the process I’ve discovered that writing skills for Alexa is a lot of fun! Like any other programming, you have to think about how people are going to use your piece of work, but unlike much of what I’ve done over the years, you can’t force the user to interact in a particular way. They can say unexpected things, phrase the same request in any of several ways, and so on. Alexa’s current limitation of about 8 seconds of comprehension favours a conversational approach in which the dialogue is kept open for additional requests. The female-gendered persona of my own science fiction writing, Slate, is totally conversational when she wants to be.

It all makes for a fascinating study of the current state of the art of AI. I feel that if we can crack unstructured, open-ended conversation from a device – with all of the subtleties and nuances that go along with speech – then it will be hard to say that a machine cannot be intelligent. Alexa is a very long way from that just now – you reach the constraints and limitations far too early. But even accepting all that, it’s exciting that an easily available consumer device has so much capability, and is so easy to add capabilities.

Artists's impression, MAVEN and Mars (NASA/JPL)
Artists’s impression, MAVEN and Mars (NASA/JPL)

But while all that was going on, a couple of hundred million kilometres away NASA ordered a course correction for the Mars Maven Orbiter. This spacecraft, which has been in orbit for the last couple of years, was never designed to return splendid pictures. Instead, its focus is the Martian atmosphere, and the way this is affected by solar radiation of various kinds. As such, it has provided a great deal of insight into Marian history. So MAVEN was instructed to carry out a small engine burn to keep it well clear of the moon Phobos. Normally they are well separated, but in about a week’s time they would have been within a few seconds of one another. This was considered too risky, so the boost ensures that they won’t now be too close.

Now this attracted my attention since Phobos plays a major part in Timing – it’s right there on the cover, in fact. In the time-frame of Timing, there’s a small settlement on Phobos, which is visited by the main characters Mitnash and Slate as they unravel a financial mystery. This moon is a pretty small object, shaped like a rugby ball about 22 km long and about 17 or 18 km across its girth, so my first reaction was to think what bad luck it was that Maven should be anywhere near Phobos. But in fact MAVEN is in a very elongated orbit to give a range of science measurements, so every now and again its orbit crosses that of Phobos – hence the precautions. This manoeuvre is expected to be the last one necessary for a very long time, given the orbital movements of both objects. So we shall continue getting atmospheric observations for a long while to come.

Timing Kindle cover
Timing Kindle cover

Who is Alexa, where is she?

Hephaestus at his forge (The Louvre, Wiki)
Hephaestus at his forge (The Louvre, Wiki)

Since as far back as written records go – and probably well before that – we humans have imagined artificial life. Sometimes this has been mechanical, technological, like the Greek tales of Hephaestus’ automata, who assisted him at his metalwork. Sometimes it has been magical or spiritual, like the Hebrew golem, or the simulacra of Renaissance philosophy. But either way, we have both dreamed of and feared the presence of living things which have been made, rather than evolved or created.

The Terminator film (Wiki)
The Terminator film (Wiki)

Modern science fiction and fantasy has continued this habit. Fantasy has often seen these made things as intrusive and wicked. In Tolkein’s world, the manufactured orcs and trolls (made in mockery of elves and ents) hate their original counterparts, and try to spoil the natural order. Science fiction has positioned artificial life at both ends of the moral spectrum. Terminator and Alien saw robots as amoral and destructive, with their own agenda frequently hostile to humanity. Asimov’s writing presented them as a largely positive influence, governed by a moral framework that compelled them to pursue the best interests of people.

But either way, artificial life has been usually conceived as self-contained. In all of the above examples, the intelligence of the robots or manufactured beings went about with them. They might well call on outside information stores – just like a person might ask a friend or visit a library – but they were autonomous.

Amazon Dot - Active
Amazon Dot – Active

Yet the latest crop of virtual assistants that are emerging here and now – Alexa, Siri, Cortana and the rest – are quite the opposite. For sure, you interact with a gadget, whether a computer, phone, or dedicated device, but that is only an access point, not the real thing. Alexa does not live inside the Amazon Dot. The pattern of communication is more like when we use a phone to talk to another person – we use the device at hand, but we don’t think that our friend is inside it. At least, I hope we don’t…

So where is Alexa and her friends? When you ask for some information, buy something, book a taxi, or whatever, your request goes off across cyberspace to Amazon’s servers to interpret the request. Maybe that can be handled immediately, but more likely there will be some additional web calls necessary to track down what you want. All of that is collated and sent back down to your local device and you get to hear the answer. So the short interval between request and response has been filled with multiple web messages to find out what you wanted to know – plus a whole wrapper of security details to make sure you were entitled to find that out in the first place. The internet is a busy place…
Summary of Alexa Interactions
Summary of Alexa Interactions

So part of what I call Alexa is shared between every single other Alexa instance on the planet, in a sort of common pool of knowledge. This means that as language capabilities are added or upgraded, they can be rolled out to every Alexa at the same time. Right now Alexa speaks UK and US English, and German. Quite possibly when I wake up tomorrow other languages will have been added to her repertoire – Chinese, maybe, or Hindi. That would be fun.

But other parts of Alexa are specific to my particular Alexa, like the skills I have enabled, the books and music I can access, and a few features like improved phrase recognition that I have carried out. Annoyingly, there are national differences as well – an American Alexa can access the user’s Kindle library, but British Alexas can’t. And finally, the voice skills that I am currently coding are only available on my Alexa, until the time comes to release them publicly.

Amazon Dot - Inactive
Amazon Dot – Inactive

So Alexa is partly individual, and partly a community being. Which, when you think about it, is very like us humans. We are also partly individual and partly communal, though the individual part is a considerably higher proportion of our whole self than it is for Alexa. But the principle of blending personal and social identities into a single being is true both for humans and the current crop of virtual assistants.

So what are the drawbacks of this? The main one is simply that of connectivity. If I have no internet connection, Alexa can’t do very much at all. The speech recognition bit, the selection of skills and entitlements, the gathering of information from different places into a single answer – all of these things will only work if those remote links can be made. So if my connection is out of action, so is Alexa. Or if I’m on a train journey in one of those many places where UK mobile coverage is poor.

Timing Kindle cover
Timing Kindle cover

There’s also a longer term problem, which will need to be solved as and when we start moving away from planet Earth on a regular basis. While I’m on Earth, or on the International Space Station for that matter, I’m never more than a tiny fraction of a second away from my internet destination. Even with all the other lags in the system, that’s not a problem. But, as readers of Far from the Spaceports or Timing will know, distance away from Earth means signal lag. If I’m on Mars, Earth is anywhere from about 4 to nearly 13 minutes away. If I go out to Jupiter, that lag becomes at least half an hour. A gap in Alexa’s response time of that long is just not realistic for Slate and the other virtual personas of my fiction, whose human companions expect chit-chat on the same kind of timescale as human conversation.  The code to understand language and all the rest has to be closer at hand.

So at some point down the generations between Alexa and Slate, we have to get the balance between individual and collective shifted more back towards the individual. What that means in terms of hardware and software is an open problem at the moment, but it’s one that needs to be solved sometime.

Hacking, QA, and software bugs

Swordfish film - Wiki
Swordfish film – Wiki

A few weeks ago I wrote about software development and hacking, and this is a loose follow-up. The image of hackers presented in films – Swordfish is a fair example, or GoldenEye – is of rather scruffy individuals who type incredibly quickly with keyboard at arms length, undeterred by all kinds of enticing distractions around them.

But most often, a successful hack is the result of careful analysis into some existing code, and a good dollop of insight into what kinds of precautions developers forget to take. In that, it shares a great deal in common with my own trade of QA. Effective software testing is not really about repeating hundreds of test cases which regularly pass – there are automated ways of dong those – it’s about finding the odd situations where proper execution fails. This might be because some developer has copied and pasted the wrong code, but it’s much more often because some rare but important set of circumstances was overlooked.

Trojan horse illustration (Wiki)
Trojan horse illustration (Wiki)

Missing values, extra-long pieces of text, duplicate entries where only one was expected, dates in weird formats – all these and many more keep us QA folk in work. And problems can creep in during the whole life of a product, not just at the start, Every time some change is carried out to a piece of software, there is the risk of breaking some existing behaviour, or introducing some new vulnerability which can be exploited by somebody.

It has been said that a great many of these things persist through laziness. One particular hack exploit – “SQL injection” – has been around for something over 15 years, in essentially unchanged form. You would think that by now, defences would be so automatic that it would no longer be an issue. But it is, and systems still fall prey to a relatively simple trick. I have worked with a lot of different computer languages, and find that pretty much the same problems turn up in any of them. As computer languages get more sophisticated and more robust, we expect them to do more interesting and more complicated things,

Estimated cost of data breaches in Germany (Wiki)
Estimated cost of data breaches in Germany (Wiki)

QA and hacking are at different parts of a spectrum, and a fair proportion of hackery goes on specifically to help firms and charities find weaknesses in their own systems. The legal distinction of when an activity crosses a line has to do with intention of malice, though a number of governments take a much stricter line where there own systems are concerned.

What has this to do with fiction? Well, Mitnash and Slate spend a lot of their time tracking down and defending against hacking in the area of finance. Their added complication is that the physical locations they travel to are scattered all around the solar system, with journey times of weeks or months, and signal times of hours. It is interesting to think about how hacking – and the defence against it – might evolve in such a situation.

In Timing, due for release in the late summer or early autumn, they are first sent to Jupiter to resolve a minor issue. It doesn’t seem very interesting or important to them. But then a much larger and more serious matter intrudes. To their dismay, the hackers – malicious ones in this case – have designed a new form of attack which our two heroes don’t really understand. They need help, and aren’t very sure they can trust their new-found helper.

To finish with, I can’t resist adding one of NASA’s pieces of artwork concerning the Juno probe, now successfully in orbit around Jupiter. It’s a great achievement, and we can look forward to some great science emerging from it.

Juno at Jupiter - NASA/JPL
Juno at Jupiter – NASA/JPL

Coding – past, present and future

'Hello World' in JavaScript (Wiki)
‘Hello World’ in JavaScript (Wiki)

Today I thought I’d write about coding. Not in a technical manual, how to do your first “Hello World” widget kind of way, but just to give a general sense of how it’s done, and how things have changed over the years. This was prompted by the passages I have been writing for Timing recently, in which Mitnash and Slate have been crafting a fix for a particularly unpleasant hacking threat. The plot is all wrapped up in blackmail and personal relationships, but their ability to code is what gets them sent here and there. But first, let’s look back in time.

Colossus being operated at Bletchley Park (WIki)
Colossus being operated at Bletchley Park (WIki)

Not so many years ago, computers were relatively simple things to work with. They didn’t look it – all the complexity was visible by way of valves and a spider’s web of cables connecting them. But the range of things you could tell them to do was quite limited. The available options were limited, and they were essentially isolated from each other. Today’s computers are almost the opposite – they look simple on the outside, but they have a hugely expanded range of capabilities, sensory inputs, and ways to communicate with nearby devices.

The art of the coder has changed along with that. Once upon a time the programmer had to do everything. If you wanted to draw a blob on a screen you had to know exactly which bit of memory to poke with which binary digit. You needed to master a whole range of disparate skills in order to accomplish quite modest tasks, and oftentimes you needed to deal with the innards of the machine’s firmware. Porting the results to a different machine was a serious challenge.

Logo Neuframe (I worked on this, long ago)
Neuframe (I worked on this, long ago)

Times have changed. If you need graphics animation, or remote communication, or artificial intelligence, there’s a library for that nowadays. Today’s coder relies on standard modules and frameworks, pulling in this one and that as the need arises. Moreover, he or she is insulated from the nuts and bolts of the device, so can write essentially the same program to run on a high-end server, a regular desktop or laptop, and any one of hundreds of different mobile devices. That is enormously liberating, but brings in a whole raft of new problems.

Does the borrowed code actually do what you want, neither less nor more? Do you trust the library writer with the innards of your system and, what is usually more precious, the data it contains? Does it already come with adequate security against hacking, or do you need something extra? On one level, the coder is freer than ever to be creative with a wealth of open source material, but to offset that, there’s a long and rather dull checklist to work through.

Some while ago I made the transition from pure development to testing and QA: it’s a decision I have had no cause to regret! I still get to write code, but it’s behind the scenes code to validate, or sometimes to challenge the work of others. QA has changed over the years alongside development. Once upon a time there was an adversarial relationship, where the two teams were essentially pitted one against the other by commercial structures, with almost no rapport or dialogue. That has largely gone, and the normal situation now is that developers and testers work together from the outset – a collaborative effort rather than competitive. There’s a lot of interest in strategies where you write the tests first, and then code in such a way as to ensure they pass, rather than test teams playing catch-up at the end of a project.

Certified Ethical Hacker qualification (
Certified Ethical Hacker qualification (

Coding and hacking are central to the plot of Far from the Spaceports, and its successor Timing. Hacking, then and now, isn’t necessarily bad. It all depends on the motive and intentions of the hacker, and the same techniques can be used for quite opposite purposes. Some of the time Mitnash and Slate are hacking; some of the time they are defending against other people’s hacks.

I have taken the line that the (future hypothetical) work of the ECRB, to – protect financial institutions against fraud and theft, would need a freelance coder more than a policeman. Moving from place to place around the solar system’s settlements takes weeks or months, and even message signals can take hours. It seems to me that it would be much more efficient for ECRB to send someone who could actually identify and fix a problem, rather than someone who might just chase after a perpetrator.

On one level, Mitnash has it easy. He can pass all the necessary but time-consuming work of testing, validating, and productionising his code to somebody else. If I ever worked with him, I’d get frustrated by his cavalier attitude to the basic constraints of working in a team, and his casual approach to QA. But then, he gets to travel out to Mars and beyond, and has Slate as his team partner.

Artist's impression: Dawn, Ceres and Vesta (NASA/JPL)
Artist’s impression: Dawn, Ceres and Vesta (NASA/JPL)

Matters of coding…

I am a little behind with the blog this week, largely because I have been making some necessary updates to the various websites that I am responsible for. Anyone who has been following the tech news over the last few years will be aware that the EU has insisted that any site using cookies should have a warning to users about this. They are tightening this right now to require that sites have some kind of popup which requires active user dismissal.

Now, along with most people in the techie world I think this is a silly regulation. There are far more effective and far less obtrusive ways that your online activities can be traced which do not involve cookies at all, so the whole mechanism gives a rather spurious sense of safety. And whatever you think of cookies, at least they can be inspected in your browser and deleted if you so choose. All the really big datasets that hold personal information about you – the ones you might conceivably be really worried about – are tucked away on remote servers to which you have no access.

But, whatever I think of it, it has to be implemented… which all takes a bit of time… which takes away from more exciting things.

Now, along the way I also discovered that several of the sites are way out of date! That is unequivocally my own fault, and I have been building up a rather long to-do list for the next few months.

So for today here is another extract from Far from the Spaceports. In this, Mitnash is also struggling with the travails of coding. Mitnash is not me, but I do have first-hand knowledge of the problems he faces! It’s a minor part of the plot, but will give him the opportunity in a few more pages to speak with a person who has information he needs.

It was time that I learned how to code the NuFleece API. So together Slate and I went through the documentation – as pitiful and contradictory as anything I had met before – and learned how to do it. This involved another trip to Aladdin’s, this time to buy a NuFleece wrap that I could practice on, and then most of the rest of the day first being baffled, then swearing at the painfully slow and irrational logic, and finally crowing with satisfaction.

Mrs Riley called me for dinner just as I got to that point. I bounced into her dining room waving the wrap about, and insisted she watch my trial template teapots drift across the surface of the wrap. They cycled through dimension and hue changes as they did so, and adapted contextually to the base colour stripes as they drifted over them. She watched them for a while as I tucked in to the soup she had brought me.

“Could you do that with pictures, Mr Mitnash? I was thinking it would be nice to have a wrap like that with pictures of the four of us on it. Riley, me, and the two children.”

I was on a real high with the afternoon’s successes.

“Drop the pictures onto this hand-held and I’ll have it done for you this evening.”

As always happens, the API work actually took a lot longer than I had expected. I promised myself again that I would stop giving ambitious estimates. So I worked into the night to get it done, and then at breakfast made a little show of presenting her with her finished wrap. She was delighted, and was still talking about it when I set off…

And here, just for fun, is another NASA image, this time of Saturn and (extremely small) the moon Tethys…

NASA picture of Saturn and the moon Tethys, taken by the Cassini probe
NASA picture of Saturn and the moon Tethys, taken by the Cassini probe

The toolkit used for producing Scenes from a Life

Spiral staircase, St John's College, Cambridge
Scenes from a Life is on its very last sanity read-through before release! All being well, this means a kindle release early next week, with physical copies through Amazon Createspace shortly after, depending how long their validation and approval process takes. Watch out later this week for the cover design to appear, a splendid composite picture which would not have been anywhere near so good without the extensive help of Ian Grainger.

So I thought I would take a short break from the slightly mind-numbing process of proof-reading to talk about the tools I have used to put this all together.

First and foremost there is Amazon’s KindleGen. Being of a technical disposition I use this “raw”, with all the actual content written in HTML, and a bunch of configuration files to tie them all together and define the structure. This means that I have complete control over the output, can check the results every step of the way, and avoid the formatting slips and navigation problems that I have met so often in both self-published and small-press books.

Next, epub format, for those many people who have other kinds of ereaders. This uses exactly the same HTML source files as kindle, but with a slightly different set of configuration files. In fact epub is a much stricter and more pedantic format than kindle, so it’s easier to work always to the stricter standard too keep both happy. Also, the diversity of ereader devices and applications, and the variations on how closely the manufacturers and software writers have stuck to the spec, means that to get wide coverage you have to be quite cautious and keep well within the bounds of what is possible. Once the source and configuration files are complete, epub is simply a zip (compressed) archive needing no special tools. Long-term readers of this blog will no doubt remember the struggles I had with this earlier in the year.

Finally, the physical copies. It has been an eye-opener going back to a world of absolute distances and dimensions for the layout. So much of my recent writing and professional life has worked in situations where text can just be reflowed at will to adjust to a different size screen or window. So, working with the constraints of a fixed piece of paper has been, to say the least, interesting.

Following the advice of my Finnish friend Petteri Hannila I tried out an online tool called ShareLatex. This takes source files in plain text, and joins them together with directives that define the physical appearance – paper size and margins, font size and type, and the whole host of conventions that go into book design. It was slow and frustrating at first, but again a technical background helps a great deal, and before too long I had got to grips with the parts of the latex language I needed for both the interior and the cover. The huge advantage of ShareLatex is that the output can go directly into Amazon’s Createspace software in “camera-ready” form. The downside – apart from its general unsympathetic interface – is that the error and warning messages when you make a mistake are exceedingly obscure. And once again, unlike just using Word and exporting to pdf, you have a lot of fine-grained control.

Which brings me to Createspace itself. This is, I think,a wonderful tool for those who are going to self-publish. Unlike ShareLatex, the errors and warnings are clearly explained and presented, and so far the process has been extraordinarily simple. I cannot yet say I have finished this – that will not happen until final proof-reading has happened, followed by the definitive page count and some last-minute accommodation to that. But so far, so good.

OK, that’s all for today… back to chapter 5… watch out for the cover in a few days…

Spotlight review reminder

Picture - Marian Allen Later this week I shall be posting an author interview with Marian Allen (Sage I: The Fall of Onagros) which I reviewed a few days ago. This post is just a quick reminder of the various other activities going on around this book during August.

Cover image - Sage I: The Fall of Onagros You can also check out Readers meet Authors and Bloggers Spotlight group or for some details and a rafflecopter giveaway. Marian’s own blog and web site is well worth looking at, as is Michelle Ray’s “1 Book Lover’s Opinion” blog. And a previous author interview with Marian can be found at The Bookworm’s Fancy blog.

I hope that there will also be some other news about mobile apps and epub books later in the week, but that depends on the speed of approval across the various app stores…

Back on the ePub trail…

This is something of a perennial topic for me, but I keep discovering new wrinkles in the ePub drama. This time it was the realisation that some vendors will accept ePub files with minor errors and some will not. In fact most will not, even if the errors are minor. So having got all excited a week or two ago and talked about how Triumphal Accounts in Hebrew and Egyptian was going live… well, it only went live at a limited number of places. I finally tracked the problem down to some errors in the ePub source files which had evaded my notice… but not the detailed scrutiny of the extremely useful epubcheck tool supplied by Google. So… problem fixed, uploads in order, and everyone seems to have accepted the file this time around. Though of course acceptance and distribution takes time so at this point only LeanPub and Smashwords have the thesis live and on sale. Google and iTunes will follow shortly…

I also had a great review of The Man in the Cistern on the Breakfast with Pandora blog – well worth a read.

Lots of other activities in the offing so watch this space next week…

Senet, ‘Scenes from a Life’, and mobile app programming

Well, all three of these have been quite prominent this week. Senet is an ancient Egyptian board game, considered by many people to be an ancestor of backgammon. Available evidence is for the most part from tomb drawings and artefacts, with a small amount of textual material as well. It is not clear how far through the various levels of ancient Egyptian society enthusiasm for the game went – the tomb evidence by its very nature preferentially informs us about elite activities and interests, and we simply do not have information either way about other strata of the culture. Senet was used, apparently, not just directly as a game, but also as a religious or spiritual symbol of the passage through this life and the next. You could liken this very loosely to today’s playing cards, which similarly straddle the long gulf between between gaming and divination in different people’s hands.

Scenes from a Life makes use of Senet quite extensively, and I have assumed that it was played very widely by all kinds of people. Sometimes in the book it is just a game, but much more frequently it features on a metaphorical level. So the journeys that take place through the book might be interpreted by the characters as like movements in the game, with all of the anticipation and anxiety that this brings about. Or there might be an analogy drawn between someone’s behaviour and a game play strategy. If, as I suspect might have been the case, Senet was something of a national game back in New Kingdom Egypt then this is inevitable. Think how sports fans tend to lace their conversation and world-view with ideas and set-piece moves drawn from their favourite sport, whether football, chess, baseball, table-tennis or whatever.

Senet app icon

So that brings us through to mobile apps. Some long-term followers of this blog will know that I have a Senet game available on the various app stores (pick your favourite store and search for DataScenes Development, or just directly for Senet). But over the last few weeks I have been working on a new version. Alongside the paid-for version there will be a free (well, advert-supported) one which has a number of geeky techie advantages.

  • By using a different underlying technology I am able to release it for a lot of phones and tablets of quite modest specification (lots more than was constrained by the previous tech choice).
  • I have integrated the app with the web so there is a sort-of leaderboard feature for those who fancy themselves as modern-day Senet champs.
  • I have taken the opportunity to rework a lot of code that had got more and more like tangled spaghetti. Anyone in the IT trade will recognise this as refactoring, and with my QA hat on I am completely aware just how many bugs get introduced by enthusiastic developers doing just this… but my code will be different…

Senet splash screen But I have also been finding some of the down-sides with the new development tool (it’s the Corona SDK for the true IT geeks). This is based on a graphics engine called OpenGL – which is magnificent for things like displaying images and moving them round the screen, but really quite poor at laying out simple text in – say – some help pages. Ironically I think I have spent longer getting the in-app help to work properly than the mechanics of the game itself.

Now, the characters of Scenes from a Life did not have smart-phones with them on their journeys. But they did enjoy the game of Senet – and you can enjoy it along with them! Realistically Senet the free game will be released quite some time before Scenes from a Life hits the bookshelves, so it can act as a sort of preview…