I’m sure many of you have heard about a chap called Tim Berners Lee who is widely credited for inventing the world wide web as we know it today. The story is well known and I’m not going to re-hash it here, however less is known about who may have come up with the first concept of the Internet. You may be surprised to hear that the origins of the concept date back several centuries and take place on an entirely different continent, among a race of people commonly considered quite primitive and barbaric. Here’s a little hint of who these people may have been.

The internet laid bare

You may well ask how the internet could exist centuries before computers had been invented or even the discovery of electricity. Naturally there was no way the internet as we know it today could be possible, however if we look at the abstract concept there are strong parallels. At it’s heart the internet is a communications system made up of a group of connected devices. The power of the internet lies in its ability to efficiently send messages through the network from one node to another. When you open your web browser and type in www.google.co.uk your computer sends a message to the web server hosting google.co.uk asking for the web page. However this message is not sent directly from your computer to the google web server, this would be very inefficient as each person that wanted to view the google web page would first need to establish a connection to their web server. As more people tried to connect to the same page the response would get slower and slower until the number of connections reached its limit.

Routing to the rescue

The internet has an elegant solution to this problem. Instead of attempting to establish a direct connection between the two end points, each of the nodes in the network just connects to their nearest nodes. So the end points are indirectly connected through the network in a similar way to this lovely node diagram:

Each message is sent with the address of its final destination, each node only needs to know what direction to send the message in order to get it closer to its destination. In this way the message is naturally routed on the most efficient path from its source to the destination. It is this concept if a nodal network and message routing that has strong parallels with a very old method of communications.

An ancient Inca network

I recently took a trip to Peru to hike the Inca trail to Machu Picchu. So this post is a (hopefully interesting) way to shoehorn some of my holiday snaps onto this blog!

However quite apart from that I learnt a great deal about the fascinating Inca culture. Before the trip I had thought that there was essentially one Inca trail in Peru leading to Machu Picchu, how wrong I was! The Inca trails actually comprised of thousands of miles of pathways connected across the whole of the Inca empire. They were the key to enabling the Inca rulers establish and run the largest single empire in South America.

One of the main uses of the trails was as a communications network. There were small guard posts dotted across the network, often high up in remote mountain areas. If the Inca ruler wanted to send a message they would encode it using a ‘quipus’, a device made up of multi-coloured plied rope, threads and knots. The exact method of encoding has unfortunately been lost in time but it may well of been a binary system quite similar to one used by computers today. It would have been quite possible to encode fairly sophisticated messages in this way.

The ruler would then pass the quipus to a messenger to deliver the message. However the messenger would only take the message to the nearest checkpoint, then pass it onto another messenger who would carry the message to the next checkpoint. Each checkpoint would be around 5-10 KM apart, more distance for flat sections and less for mountainous terrain. In this way each of the messengers could run between the checkpoints as fast as possible and the message itself would reach its destination far quicker than would otherwise be possible.

To give you some indication of how efficient this system was during Inca times the capital city was Cuzco, situated at around 3,300 metres in the middle of the Andes mountains, several hundred miles from the coast. However the Inca king was able to eat fresh fish in the capital because it was sent over the Inca trail network. It is estimated that the same delivery made by road transport today takes longer than an equivalent delivery made over the Inca network in the 15th century!

So now all the pieces of the puzzle are in place we can see that the Inca trail network used the some communication method as today’s internet. The trail checkpoints are equivalent to an internet router, the messengers have now been replaced with fibre optic cables and of course the quipus is directly equivalent to an IP network packet. So there you have it, the Inca empire invented the alpha version of the internet.

I’m loving the cherry pick command in git right now, this is the scenario that it really helps me out for.

I’ve fixed a bug on the live branch, however before it can be published to the live website it needs to be tested. So I can first publish it to our UAT (user acceptance testing) site so the client can test the changes. However the UAT site already has a bunch of other unreleased features on it. If I merge my bug fix branch into the UAT branch it will overwrite some of the other feature changes.

The solution here is to ‘cherry pick’ just my changes from my bug fix branch and commit those to the UAT branch. In this way git doesn’t merge all the other differences between the live and UAT branch.

I’ve been developing a mobile app for Android which needs to query data in an SQLite database. So the first task I needed to get done was to import data into the SQLite database. As I’m more used to writing .NET applications which use the NHibernate ORM I decided to write an import program on this technology stack.

For my first attempt at the import program I just wanted to focus on the import logic, so choose to use a ‘known working’ NHibernate configuration with a MS SQL 2005 database. While this worked fine for me it did mean that I had to manually copy all of the data from the MS SQL database into the SQLite database before it could be used in the Android app. This was quite laborious so when I needed to modify the importer at a later date I decided to change the NHibernate configuration to point directly to the SQLite database instead. This was the updated config file used:

<hibernate-configuration  xmlns="urn:nhibernate-configuration-2.2" >
    <session-factory>
        <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
        <property name="connection.driver_class">NHibernate.Driver.SQLiteDriver</property>
        <property name="connection.connection_string_name">FootyLinks</property>
        <property name="dialect">NHibernate.Dialect.SQLiteDialect</property>
        <property name="query.substitutions">true=1;false=0</property>
    </session-factory>
</hibernate-configuration>

And this is an example of the connection string format:

<configuration>
    <connectionStrings>
        <add name="FootyLinks" connectionString="Data Source=C:\path_to_the_SQLite_database_file;Version=3"/>
    </connectionStrings>
</configuration>

This configuration worked OK and the import program could connect to the SQLite database, however I hit a problem when trying to save new records to the database. This was the inner exception reported by NHibernate:

Abort due to constraint violation Club.Id may not be NULL

The problem was that the import program was using the default generator class of identity for in the NHibernate entity mappings. So NHibernate was expecting the database to generate the identity keys for the new records being saved to the database, however SQLite does not appear to support this. After some reading up on the options available for the NHibernate generator setting I decided to try the native setting. As this should select the implementation supported by the database. However this didn’t work either, I think because, of all the options native can select, none are actually supported by SQLite. So my next preferred selection was to use increment, this setting comes with a disclaimer that it should not be used in a cluster, which is absolutely fine as its very unlikely that I will ever be deploy the importer to a load balanced environment.

The increment setting worked fine with the SQLite database and should streamline my workflow nicely for updating the app data .

1. Make lowest difficulty level easier (squad numbers?, exclude older players?)
2. Correct answer page
3. Display score in game
4. Increment score on correct answer
5. Fix occasional crashing on view changes (db init to game startup event?)
6. Only allow user to select roles available at their level
7. Release one
8. Level up on score thresholds
9. Change game rules depending on difficulty level
10. Post scores to twitter
11. Update data with latest transfers
12. Release two

I recently had problems with the eclipse IDE auto-complete not working.

After Googling the problem, I managed to resolve this by downloading the source for the version I was using and extracting into the Android SDK folder, as detailed in this google code issue.