Tag Archives: software

Posted on
by

Once upon a time, time was, by and large, governed by the sun. Least ways it used to be, but then came the railways. Y’see the trouble was that time in those days, or at least our measurement of it, was typically read off the sundial in the town square. Since the angle of the sun varies with latitude this meant that while it might be 2pm in London, it may be 2.30 in Edinburgh.

This local variation didn’t really matter in a world where the fastest form of transport available ran on grass and sugar lumps, but in the age of steam trains and telegraph, it started causing problems. If a train was due in at 10:15, did that mean London time or Birmingham time? So, the rail companies started using GMT (then known as “railway time”).

Now, we live in a connected world. It is now possible to communicate anywhere in the world instantly, and oceans which once would have taken months to cross can be crossed in hours. Many of us work in teams which span continents and time zones. Age old local time issues persist; a meeting scheduled for 3pm… is that GMT, Local (currently BST) or someone else’s local time? Where exactly is the person who scheduled this meeting anyway? They’re based in San Francisco, but their calendar says they’re flying to Austin today… so is that PST or Central?

But at least you’re always talking about hourly intervals, right? Not really, what about India (GMT+5:30), or China (GMT+8 everywhere even though the country spans about 5 timezones). Oh, and what about daylight saving? Or the fact that not everyone can agree as to when the change should occur, if at all.

You get my point.

Can’t we all just get along?

In the computer world at least, there is some hope for standardisation. In the Internet connected world it is standard practice to set the computer’s system time (that is, the computer’s base clock) to GMT/UTC and then store local time as an offset from that.

This is because Unix (which historically much of the internet was built on) stores time as a timestamp defined as the number of seconds from 1/1/1970, and is always GMT. This is nice and unambiguous, and will work fine at least until 2038.

Having the base clock set to GMT/UTC by definition makes it at least possible, to convert between times, but this is far from being user friendly. As a user, this is not something I should be worrying about.

Option 1: Abolish timezones

Essentially do what the military has been doing for years and give all times in GMT/UTC/Zulu.

While this idea does have a certain appeal (to me at least, as I spend large portions of my life dealing with UNIX timestamps), given the level of international cooperation it would require, it would almost certainly never happen. Local time, with all its weird eccentricities is here to stay, least ways until some future despotic world government takes over.

Option 2: Make software do a better job (Hint: This option is the correct solution)

Computers need to do a better job of handling time on behalf of the user.

While some apps, for example Google Calendar, do an ok job, the interface always feels a little clunky. Google calendar in particular is really awkward when scheduling meetings with people in other timezones. Where exactly are my work colleagues? When would be a good time to schedule a meeting given that it should ideally fall somewhere in the work day for all of us?

When I see a date on a web page I should be able to hover over the date and have the browser (or whatever bit of software I’m using) tell me what time it is where I currently am, and my collaborators should be able to do the same. On the web, this should be straightforward with HTML5’s new semantic elements and the penchant for modern devices to come with some sort of geolocation hook.

When I am collaborating with others I should be able to see where they are, and what time it is there, whenever I need to do anything involving time. Crucially, all this should happen naturally and without the user having to worry about it.

If I were to say “Lets talk at 3:15pm”, I think it would be safe for the software to assume I meant 3.15 where I am at the moment, as this is generally how humans think. If my colleague in New York sees this the software should automatically tell them that by this I’m referring to 10:15am local time. Of course it gets a bit more complicated if I omit the AM/PM, but the software could reasonably assume that I’m more likely to schedule something for day time than night, although this assumption should probably trigger a warning of some sort to highlight the ambiguity.

The more detail I provide, the better the fix, so if I specify the timezone, then of course the software should use that (and all who view it can see this translated to their current local time).

It’s an interesting question how one should handle the fairly common situation where someone says something like “Lets meet at 3:15pm your time“. The software should probably pick this up, but if we’re currently talking to more than one person we’d need to retain an idea of context in order to make sense of it.

…and then there comes the problem of translating such pronouns into other languages. Ouch.

The point is, this is the kind of stuff software engineers should care about but nobody else should have to. Let’s do this better.

Posted on
by

Those of you who know me from my work on Elgg or building the platform powering Latakoo are possibly not aware that I also write application software. Not as much as I’d like, the lure of web services and the long tail is seductive, but while web services solve some problems they create others. In many ways, traditional application software is simpler, for one thing it’s a heck of a lot easier to charge money for.

Anyway, recently I wrote an application which lets NPPL pilots manage their pilot logbooks and keep track of the various currency requirements. The NPPL Pilot Logbook is written in Java and runs on Windows, OSX and Linux. I went from idea to product in a couple of weeks, here are some notes on what I did, in no particular order, which may be of use to some of you…

Setting the release date

Something I try and do with any of my projects is set a very short time frame for having something out of the door. The reason is that I find enthusiasm inevitably starts to wane (often this starts to set in remarkably quickly). Once this starts to set in, the chances of the product ever getting released drop exponentially until inevitably the project gets canned or it gets sucked into months or years of internal chrome polishing, which is startup death (generally this is down to fear of putting their assumptions to the acid test of the market).

Anyway, many others have written about this far more eloquently than I can, but as a rule of thumb I set the following milestones for a project wherever I can:

  • End of day 1: First runnable (it doesn’t have to do much, it may crash all the time, but you have something that runs).
  • End of week 1: First public version.

Of course, you’re not done after week one. You’ll get feedback, good and bad, you need to roll this into the next version and release that. Rinse repeat. But crucially you’ve moved your project from possibility to reality, and it’s only in one of those that your project can be called a success.

Sure, you’re going to get users complaining that feature x doesn’t work or that the software crashes, maybe you’ll see a few negative blog posts. But all these people are using your software, and taking their feedback on board is a very successful way of turning them into very loyal customers.

But remember, nothing built by humans is ever perfect and the opposite of love is not hate, it’s indifference.

Language and platform choice

My target audience uses a variety of different computers, often without an internet connection (hence why I decided to build this as a desktop application in the first place). So, I was aiming at building something as multi-platform as possible. My development environment is entirely Linux, with an Windows XP VM I keep kicking about primarily so I can sync my iphone on itunes, so I also wanted something I could build natively.

I considered C/C++, but while all multi-platform stuff is going to be write once, debug everywhere, the trad C/C++ route seemed to be the most painful. Certainly when it comes to decoding the Win32 API or trying to link to wine libraries.

So, the choice was between Mono/.NET or Java. I picked Java, for no reason other than it seemed to present the fewer hurdles and it seemed to have the more mature tool chain. That said, I’m watching Mono with a keen interest.

Writing the code

I wrote some code, I leave this as an exercise for the reader. Under the hood, the NPPL Logbook is not a terribly complicated piece of software, I used Swing for the UI put together with netbeans and using their UI extensions.

A couple of very specific points:

  • Home directory: there seems to be no reliable way of getting a home directory location in a multiple platform context, and you can’t rely on user.home being set. So, writing configuration files can be interesting, especially if the user chooses to install in program files under windows.
  • Give the OSX dock bar a nice title

Deployment

I admit that this is still a little bit of a work in progress for me. Windows has by far the most mature deployment tool chain, with many good free installer construction kits.

Mac works from directly running the .jar archive, intelligently extracting the .zip file to a seemingly sensible location. Linux is still a little fragmented, although I do remember that .deb archives are pretty straightforward to build. Since the Linux demographic is highly technical I figured a .jar archive and a linux launcher would work for them.

The Website

My requirement for the website were that it should look (reasonably) professional given my limited time and graphic design skills, and that it should not be a time sink (as they often are). So, I got an appropriate domain (nppllogbook.com) and deployed the latest version of wordpress with a businesslike free theme I grabbed from wordpress.org.

It took a couple of days, off and on, to tweak the theme, install plugins, do basic SEO, write pages and get the site to a state where people could actually download my software (and as a by-product I open sourced a handy tool).

Next comes…

Having a way to get paid

I leave this until last, but it is obviously not the last in priority. From the beginning I had a simple business model; build something that solves a problem, sell it to people who have the problem it solves. To do this you need to be able to accept money (obviously), and if you don’t have an easy way for your customer to give you money you have problems.

As a non-US based company, this actually proved somewhat problematic. The new best of breed payment systems that world+dog seem to be using these days (Braintree et al) are pretty much US only, unless you want to slap some cash down up front to get a traditional merchant account with a bank.

This basically leaves you with Google Checkout or *gulp* Paypal. I tossed a coin and lumped for Paypal, which isn’t too painful providing you avoid their tight integration. I wrote another tool to generate registration codes, and use Paypal’s notify api to trigger an endpoint, which emails a registration code to the customer.

The headache I get every time I have to implement a payment system was mercifully small.

What next?

So, the NPPL Logbook is out there, you can download it and even pay for it (and if you’re a private pilot, I would encourage you to do both!).

Right now I’m spending time promoting it, as well as processing feedback to feed into the next version, and working on other product ideas. That’s another take home – you’re never done, and that’s a good thing!

Anyway, hope this rambling stream of conciousness will be useful!

Posted on
by

The Raspberry Pi is a tiny, solid state, and ludicrously cheap hobby ARM based computer designed in the UK (but thanks to insane UK tax laws needs to be built in China). It has a USB port, video, sound, an Ethernet port, 256MB RAM, and can run 3 distinct flavours of Linux.

Ostensibly the device was developed with the aim of getting kids to code, and as someone who grew up with the UK hobby computing scene of the 1980s and cut their programming teeth hacking games together on the ZX Spectrum, this is something I can thoroughly get behind.

The blurb from their website:

The Raspberry Pi is a credit-card sized computer that plugs into your TV and a keyboard. It’s a capable little PC which can be used for many of the things that your desktop PC does, like spreadsheets, word-processing and games. It also plays high-definition video. We want to see it being used by kids all over the world to learn programming.

Coming out of Cambridge and with a decidedly hobbyist feel to it, the Raspberry Pi could almost be the spiritual successor to the humble and much loved Speccy. If it can get more kids coding then that’s all for the good, especially if it gives the UK tech scene a much needed shot in the arm.

This is not the reason why I’m excited.

Small. Capable. CHEAP.

The Raspberry Pi is tiny, which means it can be put in tiny things. It is low power and solid state, which means it doesn’t need much juice to run (4 AA batteries will do the trick) and it can take a fair amount of abuse.

Above all, it is cheap, and this is why I’m really excited. They are certainly something you can afford to buy more of than a traditional computer, even on a modest budget. I’d go further and say that they are so cheap that they can be thought of as practically disposable general computing units… this is game changing.

The reason I am really excited about this is that all these factors combine to make them the perfect choice for the control computer for any number of appliances or devices, and it reduces the barrier to entry for the home hacker to start putting some really cool things together.

I don’t think it will be long before we start seeing countless hobbyist developed bits of hardware; from internet radios, to cheap NAS appliances, right through to remote sensor platforms, robots, drones and maybe even spacecraft. Given the number of bits of Lego sent to the edge of space recently I don’t think this is too far off!

Increasingly you don’t need to wait for a company with a massive fabrication plant to see a market for a product in order to get one, but now micro-manufacturing is something you can do in your own home. I can think of hundreds of gizmos I could spend countless afternoons building with a Raspberry Pi at the centre.

I can’t wait to get my hands on one!