TV Guide Update

It's been a while since I've posted an update on my TV guide application.  There are now two versions: one in Qt for desktop systems, and a second in Java for Android 2.2+ devices.  Both share some features in common:

• Built-in support for the free OzTivo guide service for Australian TV channels.
• Select a channel and date to show the programmes for that combination.
• Customise the channel list, both Free-to-Air and Pay TV.
• Create a bookmark for an episodic show to highlight it whenever it is on.
• Using web search engines (Google, IMDb, etc) to find details on a selected programme.

In addition, the desktop version can:

• Show multiple channels side by side in column form, similar to a paper TV guide.
• Export bookmarks in XML format, for copying your bookmarks to a mobile device running the Android version.
• Create groups of channels to reduce clutter when viewing multiple channels.
• "7 Day Outlook" mode that shows all of your bookmarked shows for the next 7 days - essentially this is your "viewing list".
• Searching all displayed programmes for certain terms, categories, actors, etc.

The mobile version also has some special features (and will get more of the desktop features as time goes on):

• "Bulk Download" of guide data to the SD card of up to 5 days worth of data.  Excellent for offline use, or to save money on 3G by only downloading when you have access to cheaper Wi-Fi.
• "Add Reminder" to add a showing to the mobile device's calendar application so you can be reminded 10 minutes ahead of time that your show is on.

The mobile version is the "new shiny" of course.  Android 2.2 is a fairly simple SDK to work with - the heavy lifting for the application was done in about 4 weeks .  It helped that I'd already spent 6 months refining the desktop version (many, many, blind alleys before getting the feature set right).

For a quick tour, here is the mobile version's opening screen:

Selecting a channel shows a tabbed view with the programmes for today and the next four days:

Press-and-hold on a programme pops up the item menu:

It's all pretty straight-forward after that.  The main feature that makes this more than a simple TV guide is bookmarks.  It really helps to organise your week's viewing and to be notified when your favourite shows move to another timeslot or return for a new season.  In the desktop version, I almost never look at the normal view.

So, play with it and let me know how it goes.  I use it every day and have not bought a newspaper for a paper TV guide in months:

• Source code: https://github.com/rweather/tvguide
• Download Android APK file: https://github.com/rweather/tvguide/downloads

For those who've never installed an APK before, the steps are fairly simple:

• Download an "APK Installer" from the Android Market (any will do).
• Check "Unknown Sources" under "Settings -> Applications" on your device.
• Mount your device via USB and copy the APK file to the SD card.
• Install the APK with the aforementioned installer and have fun!

Fun With LEDs

I've been replacing mains power gadgets around my house with battery-operated versions for a while now.  An average bedside alarm clock designed to run from the mains will consume up to 6 watts, or 50 kWh of power a year.  A travel clock designed to run from a AAA battery will run for the same period on the equivalent of less than 1 kWh a year.

The latest to be replaced is the bedside lamp.  I bought a mechanic's LED torch on a stand that ran off 3 D cells.  Worked reasonably well, but not as bright as I had hoped.  Unless it is pointing right at the book you are reading, it doesn't illuminate much.  So I decided to build my own LED-based lamp, using one of these:

That's a Cree Super Bright White LED.  100 lumens of white light, driven by 3 volts @ 350 mA, with a beam angle of 90 degrees. For comparison, a traditional 60 watt light bulb puts out 800 lumens. Here's the finished product:

The circuit is built inside a box with a clear lid, pointing straight up.  The original plan was to put a diffuser on top of the box to spray light in all directions.  I tried various diffusers, but the best was a bottle of clear marbles:

Turned out I didn't need the diffuser after all.  100 lumens across the 90 degree beam angle spread means that sitting on the bedside table, pointing straight up at the ceiling, it lights up the whole bedroom.  More than enough to read by.  And then some.

Power consumption is 1 watt, and should get about 30 hours on the two D cell batteries.

Parts list (with Jaycar part numbers):

    ZD-0442 - Cree XR-E Super Bright White LED (or Warm White ZD-0444)
    HH-8580 - Heatsink for LED
    AA-0590 - LED driver module, 3V to 350 mA
    PH-9218 - D cell battery holder x 2
    ST-0554 - Toggle switch
    HP-9556 - Veroboard PCB
    HB-6248 - Polycarbonate box with clear lid
    HP-0815 - Rubber feet
    Optional: 25 degree collimator lens (HP-1297)
    Mounting posts/spacers/nuts for the PCB
    Double-sided mounting tape for the battery holders

Total cost of parts is about AUD$90, batteries not included.  And here is the circuit diagram:

If you use the collimator lens to focus the light upwards, then you'll also need a diffuser like the aforementioned bottle of marbles.  Or stand it on its side to use it as a directional torch!

Bug databases and git

I've been using ticgit-ng for my TV Guide project for a few weeks now.  It is a simple ticketing system that runs directly in your git repository on a hidden ticgit branch.  Very nice.  No need to set up a separate bug database - just type ti list or ti new and you're off and racing.  There is a web interface as well, but I didn't bother with that.

The tickets are stored as flat directories and files within the repository.  Updates are normal git commits just like any other, and can be pushed up to your central repository.  A simple git pull followed by ti sync is sufficient to sync the ticket history with that pushed by someone else.  Here's the history and an example ticket for the TV Guide:

• https://github.com/rweather/tvguide/commits/ticgit
• https://github.com/rweather/tvguide/tree/ticgit/1310191258_channel-icons_931

And here are my current open tickets, from ti list:

   TicId  Title                    State Date  Assgn    Tags
---------------------------------------------------------------

   daae6d Global search            open  07/09 rhys.we…

   1bc66e Export/import bookmarks  open  07/09 rhys.we…
   33bb19 Programme view widget    open  07/11 rhys.we…
   e37deb Underrun/overrun report… open  07/20 rhys.we…
   af4bbe Partial matching on a p… open  08/14 rhys.we…
   9e8ad6 Inverse bookmarks        open  08/19 rhys.we…
   0a96ec Category matching in bo… open  08/21 rhys.we…
   8a1e8f Android application      open  08/28 rhys.we…
   d04472 Improved 7 day view      open  09/02 rhys.we…
   b4d129 Sorting in bookmark list open  09/03 rhys.we…
   921e49 Partial match is hard t… open  09/05 rhys.we…

Now, ticgit is a little simple compared to "enterprise-quality" bug tracking systems.  There are only 4 ticket states: hold, invalid, open, and resolved.  And the users need write access to the git repo or the web interface.  So ticgit may only be useful for 3-4 person projects.  But that shouldn't stop someone making a larger system using the same concepts (ticgit is written in Ruby).

The main thing I like about using git for bug tracking is that it could solve an annoying problem with continuous integration (CI) systems.  At my previous job, our features and bug fixes were done in "staging repos", which the CI system would automatically integrate, build, and test.  Any compile or unit test failure would toss the staging repo contents back so that the mainline was not polluted.

All well and fine - except for bug reports.  When a developer marked a bug as fixed, there was a good chance QA would re-open it soon thereafter because the fix wasn't in their mainline-based build yet.  So developers routinely would add copious "Fixed in SHA-1 in staging repo blah, branch foo" comments to ward off bugs being reopened too soon.

With a git-based system, the update to the ticket could be made in the staging repo as well.  The mainline repo's copy of the ticket will still show "not fixed", but once the staging repo passes CI, the ticket changes will be merged as well.  At all times, the tickets reflect an accurate picture of what is in each staging repo and mainline.

The ticgit system isn't perfect though.  I'd actually prefer the tickets to be stored in the master branch, so that the commit that fixes the bug in the source code also updates the ticket state.  It is common to update the source code, documentation, and unit tests in a single SHA1 - there's no reason why the ticket state change couldn't be made part of the commit as well.

Gamification, what is it good for?

I've been seeing ads on Sci-Fi Australia for a couple of weeks now for the Clustr application for iPhone and Android.  Apparently a social networking tool to talk to other sci-fi fans, rate shows, etc.  OK, whatever.  Such sites are a dime a dozen on the Internet.

But the thing that really pushed my "Why do I need this?" button was "Unlock exclusive Doctor Who badges".

Er?  What?  As best I can tell, they are pictures from the Doctor Who series that turn up as little pictures in the application once you've won a prize or something.  Ever heard of Google Images guys?  If I wanted a nice picture of my favourite Doctor Who character, then I'm hardly going to sign up to a service that wants the following privileges on my phone:

• Full Internet access.
• Fine GPS location.
• Read contact data.
• Modify/delete SD card contents.
• Prevent phone from sleeping.

The whole application seems to be an example of Gamification, designed to harvest personal information in exchange for postage stamp sized icons that I could Google for myself.  No thanks.

The PC is going away! Tablets rule!

So one of the original designers of the IBM PC said that the PC is going away.  Yeah right.

The PC is not going away.  The important thing about a personal computer is the personal, not the computer.  Whether it is the size of a wristwatch or a fridge, the most important thing about a PC is this:

Some control freak in the machine room cannot tell you what you can do with the computer and when you can do it.

That was the fundamental change that came with the Altair 8080 and the first IBM PC.  Not the form factor.  The PC gave everyone local processing and storage capacity that wasn't charged by the CPU second or the kilobyte.  Capacity that didn't need forms in triplicate to access.

A tablet is merely a desktop PC with the keyboard removed and distributed in a more mobile form factor.  It can run some types of applications very well, but others very poorly.  Reading other people's web pages is nice on a tablet.  Try creating a new web page for yourself and you'll want that keyboard back.

The biggest threat to the PC is not tablets or smartphones (which are just PC's).  It is cloud computing.  Because that puts the control freaks in charge of your data again, and reduces the device in your hand to little more than a dumb terminal.  Resist that to your dying breath.

The control freaks never went away - they have MBA's these days and think that computing is only useful if they can charge you by the CPU hour or the gigabyte, or charge someone else to insert ads into your data whenever you access it.  They are reshaping the entire computing world to serve their business models rather than your personal needs.

When someone talks about the death of the PC, they are trying to send you back to the world of mainframes, dumb terminals, and central control by crippling the devices you use.  Ignore them.

What's on the tube?

For most of my life I've bought the Sunday paper for the TV guide.  Even recently, when the rest of the world switched to EPG's.  The main reason for the procrastination is that EPG's suck.

Typical EPG's display a tiny snapshot of the guide - a small number of channels and the next couple of hours of programs - all in a 40 point font designed to be visible to blind granny on the other side of the room.  Navigation with the up/down/left/right/OK buttons on a remote control is also a pain.  My kingdom for a QWERTY keyboard and a mouse!

Here are some use cases that EPG's fail at miserably:

• Draw a circle around your favourite show.  Not to record it - just to remind you that you may want to watch it.
• Tell you if a program has moved to a different timeslot.
• "Oh cool!  Doctor Who is back on again!"
• Noticing a new show out of the corner of your eye - the narrow two hour view of an EPG makes this impossible.

My attempt to improve upon EPG's is a Qt 4.7 based application for the desktop.  No DVR integration or HDMI control protocols.  Just you, your laptop, and the TV guide.

Plain boring desktop Qt application (patches to add a QML front-end welcome, although the whole point of this is taking advantage of the big screen).  The guide data for all TV free to air and Pay TV channels in Australia comes from OzTivo in XMLTV format, and is quite comprehensive.


Most of the use cases are handled with the "bookmark" feature, which displays your selected shows in a chosen color - altered slightly if the timeslot or day doesn't match.  The "7 Day Outlook" feature will display the bookmark matches for the next 7 days on a particular channel (or "All Channels" if you select it), which acts as your "viewing guide".

Code here: https://github.com/rweather/tvguide
Documentation: Press F1 for help.

Plang documentation and status report

A snapshot of the Plang documentation has been uploaded here.

Plang is coming along nicely.  The core language and builtin predicate set are fairly close to complete.  Performance is being worked on - I added an interpreter for the Warren Abstract Machine to speed up predicate execution (still more to do on that front).

A sample of the cool features that have been implemented to date:

• Fuzzy logic for reasoning about information that is "partially true".
• Definite clause grammars for natural language sentence parsing.
• Support for WordNet that provides access to information about hundreds of thousands of English nouns, verbs, adjectives, and adverbs.
• Object model and class definitions  based on JavaScript's prototype-based inheritance scheme.

I'm starting to shift my focus to writing applications in Plang to see how well it tackles the traditional logic programming problems of theorem proving and AI.  There's no point building a new language if it doesn't do the job better than the old one, after all.