Yesterday I said that to date, the Diaspora devel­op­ers had “failed to inte­grate their most basic premise into the soft­ware design. They’ve missed the point from first prin­ci­ples.” Well, a couple of friends on Twitter called me out on this and asked whether I’d actually checked out the back-end code to be sure about my accusations. Maybe Diaspora was just lacking a UI to make the relevant changes? This is alpha software, after all.

Well, they had a point. And thanks to the beauty of open source source, I was able to download the source code directly and take a look for myself. I only got as far as looking at the database schemas, but it looks to me like the database layer would require significant work to bring profile information into their aspect-based privacy model.

The aspect model is clearly built around controlling visibility of posts, which starts out by encompassing “wall posts” and will cascade to include comments, photos, mentions, videos and everything else that flows from there. At first glance, the team have done well. They seem to have laid the foundation of their privacy approach on bedrock, building their philosophy into the software from the ground-up. Their initial design will naturally affect everything based on their central idea of a “post” as the network grows and features are added.

The only problem? Profile information does not sensibly fall into this model in any way. It’s currently stored in fields in the Profile model in a non-extensible way which is entirely disconnected from posts. To allow profile information to fall into line with the rest of their aspect-centric approach, they’d need to refactor the user profile models pretty heavily (which admittedly they will likely want to do anyway eventually, given the limited nature of their current design) and they will also have to rework with the basis of the aspect model or the way in which users and user profiles are connected.

In other words, their foundations aren’t built on bedrock at all. They’ve laid them two storeys up, establishing their groundwork on top of the hastily-constructed user model they already had in place.

Fixing this omission certainly doesn’t look like a trivial job. And in addition, let’s not forget that any reworking of their basic models at the database layer would naturally have to fall through the rest of the MVC layers to the UI too. This is not an insubstantial overhaul. Given that the Diaspora project doesn’t even have a note about this on their roadmap, my initial assumption that they’ll have to hack this support in and bolt it on later when it’s too late to refactor properly seems accurate.

All of the above shouldn’t be taken to mean that nothing can be done and the problem is unresolvable, but there is a reasonable amount of work involved and it would mean pretty fundamental changes to their core models. It’s not something that could get implemented as a quick patch; this change would require full support of the core development team. Open source is indeed beautiful thing that enables us to trust our software and gain understanding of how it works, but sometimes you just have to hold your hands up and admit defeat.

Diaspora is fundamentally missing the point of their own philosophy, and there’s nothing we can do but wait and see how they end up fixing it later down the line. Will it be a Facebook-style mess of privacy controls? I hope not, but at present the odds aren’t looking good.

It’s a bit dead at the moment, and very lacking in features compared to any other service you might care to join, but that’s fine. It’s in alpha, and missing features are to be expected (along with a good helping of bugs). My real issue with the service, and the one that lead me to compose this blog post under such a dismayed title, is that Diaspora is already failing to meet the expectations they set about control over privacy and sharing.

One of the core thrusts of Diaspora is the big bold message on their homepage: “Share what you want, with whom you want.” In accordance with this, they have implemented aspects: contacts must be categorized into different sets of users (which may overlap as required) so that you can choose what you share and only disclose it to the chosen contacts. This, they suggest, allows you to share the 3 nice pictures from your night out with colleagues while your friends can see the full damage (i.e. the other 47 images). It’s a nice idea, and one that appeals to me. It’s simpler than Facebook’s messy privacy model and seems to be built-in from the ground up. Or does it?

One of the first things I tried to do was to hide my birthday from anyone other than close friends and family. It’s a silly thing, but I thought it would be nice to share my real date of birth only with my friends; the rest of the world should see nothing, or perhaps just the year in which I was born. Not a big deal, but a reasonable thing to want to protect given how often date of birth is used in various security mechanisms.

I flipped to my Profile Settings, but couldn’t see how one might restrict certain parts of one’s profile to particular aspects. Neither biography, location, photo, or birthday could be hidden away. It’s not just that I was in the wrong part of the website, which was my first thought: there is no way to control which of your contacts see which parts of your user profile.

This is a very basic starting point. Even Facebook gets this right. Yet Diaspora—the social network that allows you to “share what you want, with whom you want.”—has missed the point entirely.

I know this is almost silly. After all, there’s not much in your profile you’d realistically want to restrict at present. But there are use cases for doing so now, even paranoid security reasons. And what’s more, when you can eventually add information like employment details, religion or sexuality, one might very well want to restrict certain information to close friends or family.

I did post a contracted version of this rant on Diaspora itself, and a friend commented that perhaps I should try to get involved with development. It’s not a particularly satisfactory response. Indeed, the only bad thing about open source technology is that one cannot make disappointed noises without somebody else suggesting they get involved and fix the issue themselves. It’s a poor response when people say it on the Gentoo forums, and it’s a poor response when it gets trotted out on a social network too.

To date, the developers have failed to integrate their most basic premise into the software design. They’ve missed the point from first principles. And, like security models, trying to bolt the right behaviour on to the application later down the line will be a losing battle: you’ll never plug all the holes. I’m not sure any individual hacking on the existing codebase can make a real difference.

Despite all of the above, I will indeed keep a close eye on Diaspora and I’m not going to give up on it. But at present, the disparity between their marketing blurb and their software is almost unpalatable.

Inline XBRL, otherwise known as iXBRL, is an incredibly elegant solution to financial reporting. A derivative of XHTML, iXBRL allows users to produce human-readable documents that can be rendered in web browser while also allowing them to embed additional structured data. When processed by a compliant processor, an iXBRL document is transformed into an XBRL instance document—a format used by governments, regulators and analysts worldwide. For those of you that don’t work in the world of financial reporting, iXBRL really is a very neat option: the very same data that is read by human eyes can be transformed into an XML–based machine-readable format by any iXBRL compliant processor, allowing a single source document to be used by analysts and BI tools alike.

For the average user, iXBRL means that the documents seen on-screen are comparable to the Word documents, Excel documents or even PDF documents which they are replacing (and in many cases, the documents from which they were generated). Provided it doesn’t hinder machine-readability or require duplication of data, this familiarity can only be a good thing. The fact that iXBRL also hides away the hideous angle-bracket-and-slash-infected nature of XBRL doesn’t hurt either. XBRL may well be a great format which is ideal for consistent, comparable, and processable financial reporting, but it’s miles away from anything an accountant would actually want to use or understand.

On a global scale, iXBRL is going to be a big deal primarily because it solves the kind of problems that the US have been enduring for years. The largest corporations in America have to file their 10-K and 10-Q reports to the SEC, but they have to file two copies of their returns: one in XBRL format, and one in HTML format. One provides structured data, and the other merely allows the analysts who have been relying on readable returns for decades to continue doing their jobs. This leaves us in a horrible half-way house, with duplication of effort (and data!) plus a boring, tiresome job comparing the two documents to ensure that they are consistent. Worse, it means that everyone can ignore the XBRL filings for a few more years and work with the same HTML EDGAR filings they’re already comfortable with—reducing the impetus for companies to produce high-quality XBRL returns.

In the UK, the sharp charge to iXBRL has delivered all of the benefits of HTML and XBRL formats while cutting out the drawbacks of being forced to prepare both. I’d be willing to bet that even though the UK is the first country to make the leap to iXBRL, it won’t be the last.

Welcome to the world stage, iXBRL. You’re a welcome addition to the stable of financial reporting formats, and I bet you’ll also be one of the most durable.

My process used to be laborious: visit Bennet Yee’s Area Code Listing, by Number and look up the state to which the area code corresponds, visit Wikipedia and look up the capital city of the state, then visit the World Clock Meeting Planner and see how our timezones overlap. This got old pretty fast.

I’ve solved this problem with Sundial, a US telephone number to timezone converter. It’s a simple webservice which takes any old telephone number and, if it’s a US number, produces a timezone comparision chart to show how it corresponds to GMT. Sundial is freely available for public use, so please give it a try!

You can use Sundial in a few different ways. The simplest is to visit the Sundial converter and enter a US telephone number that you would like to lookup. Format is not important—stick it in with brackets, periods, warts and all. Alternatively, to convert Mobile: (651) 342.2323 you can just navigate directly to http://benjaminasmith.com/tools/sundial/Mobile: (651) 342.2323 and get the answer you’re looking for.

My favourite way to use Sundial is via Firefox Smart Keywords. Using smart keywords, I can just type:

sun Mobile: 651.342.2323

To set this up, just create a new bookmark to http://benjaminasmith.com/tools/sundial/%s and give it the keyword sun.

Sundial is still under development, so I’d love to hear any suggestions you might have or fix any bugs you might come across. Let me know how you get on in the comments, or drop me an email.

The reactions to snow are mixed. For some, they fear the hassle it brings: disruption to travel, to deliveries, and to daily routine. It brings wet carpets and cold ears; school closures and icy pavements; slippery surfaces and soggy trainers. For others, snow is a blessing. It brings snowballs and sledging; quality time with the kids; days free from the commute and free from the office. And for many, it means a day off. But just because it disrupts routine, why should it destroy productivity?

Snow seems to be the only form of weather which can reliably bring British business to its knees. After the recent snow, absence management organization FirstCare estimated that nearly 11 per cent of the UK workforce stayed at home—the highest figure ever recorded for December. Meanwhile, The Centre for Economics and Business Research estimated that this spell of absenteeism costs us over £1 billion per day. That’s over 26% of Britain’s daily GDP.

The key question for me is not why 11% of the UK workforce stays at home, but why staying at home carries such a high cost to businesses. Why does a little snow (or even a lot of snow) cost us 13% of our daily GDP?

In 2009, it was estimated that 73% of the UK GDP came from the services sector. In today’s world, services means far more than tourism and transport: it also means finance and business services, many of which are essentially virtual. What do I mean by “virtual” services? I’m referring to services which at their core do not directly relate to physical products or the movement of materials. They relate to concepts, to ideas and to important information, yet they do not require a physical backdrop. These are services like accounting, advertising, design, programming and support. To an extent, even telesales, recruitment and many real estate services fall into this category.

ONS statistics show that even in 2000, over 10 million people were employed in virtual sector jobs against a backdrop of over 25 million workers employed within the wider services sector. The virtual sector makes up approximately a third of the UK workforce, yet accounts for closer to half of UK GDP. In today’s climate (both meteorologic and economic), surely the overwhelming majority of virtual sector should be able to work from home and reduce the cost of snowfall?

There are plenty of examples of how companies can function even while staff work from home, and plenty more examples of companies failing to think ahead. I’m going to pick out two.

I’ll start with a software house in Oxford at which many of my friends are employed. When their offices are snowbound or employees are faced with a rather slippery uphill struggle to get to work, they are all provided with myriad sensible ways to work from home. For some, this is as simple as using the same laptop at home as at work. For others, it is centred on good, thorough documentation and a reliance on free, open source software. Sensible email access policies allow users to get set-up from home, and employees are provided with secure access to the company intranet through use of free, multi-platform, open source software like PuTTY. Because the company base so much of their operation on open source software, employees can freely install almost any of the other tools they need to do almost all of their work from home. It’s not ideal, but it’s pragmatic and allows for solid productivity even in the worst conditions. All they need is internet access.

Let’s take a rather less impressive case: Ebuyer, the online electronics superstore. Snow hits, and their deliveries take a hit—something which is perfectly understandable given the location of their offices in East Yorkshire. However, not only do their deliveries struggle, but so do their telephone lines. When the snow came down in early December, their telephone lines were closed for days and email enquiries received very limited responses. This was apparently because their staff could not make it to the support centre. But why did staff need to be in the centre to work?

There are many free or cheap solutions to route telephone calls that do not require a physical dedicated line hooked up to each handset, and indeed virtually every call centre already uses these. There are also plenty of good and cheap solutions for routing calls over IP. As for remote email access: this is just a given in the modern world, and all it takes is for a plan to be in place. Could staff not have been provided in advance with a spare headset and any required documentation to allow them to sign-on and work from home? Perhaps this is impossible with the systems that Ebuyer have in place, but with a little prior planning and good choice of technology it seems very unlikely that the problem could not have been avoided.

The key point is that with a little preparation and a little technology there is almost always a way to allow virtual sector employees to be work from home. There are so many solutions which are already in use for this very purpose—an increasing number of which are already in your IT infrastructure, are freely available, or can be cheaply deployed from the cloud. This is a solved problem from the technological standpoint. Connectivity is not an issue even over great distances, and bandwidth is largely free for consumers, so why not make use of it? Why are we still left to flounder when the snow settles?

This is a call to arms. Management: get prepared, talk to your system administrators in the New Year, and make this happen. It might require a little effort and a little will, but it can be done and will deliver huge savings to your business even in the medium term.

Everyone else: go outside and make the most of the snow while you can. This time next year you might find yourself not skiving and sledging, but working from home. At least you’ll get to skip the commute…