Wednesday, May 25, 2011

Tracking Online Transactions

http://www.technologyreview.com/blog/editors/26785/

This is an interesting little snipit about the transactions involved behind a spam advertised product.  The thought that comes to mind is the similarity to the drop-shipping model that has proliferated on ebay and other online auction sites.  The funniest thing is that every time some politician smiles brightly and talks about the wonders of free trade and the global ecconomy... this is actually what it means.  Not that I am being critical. This is a healthy thing.  It's the organisational structures that are not yet in place to regulate this sort of thing.

Its actually even funnier when you read about all the arguments and counter arguments about online music piracy and the arguments about how the old economic model is dead and how the music companies need to evolve etc etc. The thing that everyone forgets is that every economic transaction will evolve in a similar way.  EVERYTHING!  Any product our grandparents could purchase from a shop can now be delivered across the internet.  Very soon any service short of those requiring specialist equipment or personal contact will be able to be partially or completely delivered via the internet.

If you think the flight of jobs to cheap labor sources has been rapid up till now... just you wait.  For every new country that gets good, universal connection to the internet, we will have another round of movement of jobs and infrastructure in to exploit the unemployed for cheap labour and the wealthy for customers.

The long game in all this is that the internet will provide a degree of leveling, in that wealth and employment will flow to countries with cheap labor and low employment conditions while wealthy countries where labor costs are high will be drained of both employment and capital. 

This has been happening for the past few decades, so this is not exactly rocket science.  The point that I find eternally amusing is how little the political machinery wants to accept this reality.  Politicians are the last to change.  The absolute last to accept that that status quo in not maintainable.  Simply because they are only in their position by promosing to maintain the status quo ( or return to a previous idyllic status quo that the population of voters remembers fondly ( see Russia for an example of that particular issue))  But as much as I can point at Russia... I think they are just the leading edge. Half of western Europe is going through economic collapse at the moment, so they should probably be looking at Russia for guidance rather than treating Russia as some kind of "never happen here" case.
But politicians being politicians, they all want to pretend that some how they can roll back to a better time.  Just like the climate debate, "we can undo the damage" just tax carbon etc etc.  Bullshit.  There is no going back.   We can certainly tax carbon but that will just create a carbon market. If it has an incidental effect on the amount of greenhouse gas... well that's nice too.

The point is that the Internet is a transformative technology for everything, wealth, culture, community, politics, technology etc. simply because it has expanded everyones ability to access all of the above.

Are there down sides... you betcha.

Monday, May 23, 2011

Skeleton CSS base system

http://www.getskeleton.com/#mobileFriendly

Handy toolkit for building mobile friendly apps quickly.  Very nice.

Thursday, May 19, 2011

http://chronicle.com/article/Dumped-On-by-Data-Scientists/126324/

Article on problems with large data sets in research.

Flaws in data anonomyzing

http://radar.oreilly.com/2011/05/anonymize-data-limits.html

Article on some rules for dealing with public data sets and the problems with the idea of "anonymous"  in data sets.

Wednesday, May 18, 2011

nanolaw fiction

http://www.ftrain.com/nanolaw.html

This is a nice piece of speculative fiction.  Short, sweet... bit rough in the finish.  It looks at the intersection between the online micropayments model and the American legal model and how that may play out in a connected world in the near future.

Tuesday, May 17, 2011

Rant on Exception Handling Strategy

I have finally made some peace with exception handling... again.

After refactoring the way I thought about exceptions so many times, I have come to a couple of (probably not new) realizations.

1. The program should never crash. It should exit gracefully even if its going out backward in a cloud of smoke. A programmer who lets an exception smash his software is just not a contender. 

2. All exceptions should be caught and reported in a controlled way as close to the root of the program as possible.  This results in the main() being a very thin wrapper around the top level exception catch.  (Since its always a fairly thin wrapper around the root object creation point, this is no bad thing.)

3. Yes exceptions come in three flavors. User errors, programmer errors and system (environment) errors.
 - User errors are violations of the assumptions of the user and need to be explained clearly and in detail. Usually with some sort of reference to "More Information".
 - Programmer errors ( bugs) are violations of the programmers assumptions.  These are things that should not exist in the finished product but usually do.  They need to be reported in enough detail to be reproduced, identified and fixed.  This may be a detailed log, stack dump, whatever.
- System errors are violations of the programmers/users assumptions about the state of the environment in which the software is running.  As this is usually a dynamic system... to a certain extent... shit happens.
These need to be handled when they can be handled, reported to the programmer when they cannot be handled and apologized for to the User. 

4. Most exceptions are not explained in a useful fashion and need to be translated. Even for programmers.  They all have dynamic context that should be captured as close to where they are thrown as possible.  There is no point letting a weird exception unwind the stack and erupt at the high level handler with a cryptic message and no contextual information.  Its just wasting everyones time. So catch it at the site, decorate it with all the nice contextual information that will make it understandable and the let it rip.

5. My custom exception class has two messages. One for the User and one for the Programmer.  Even when its the users assumptions being violated, there is useful information for the programmer.  This needs to go into an error log.  Even the fact that lots of users have a similar error means you should probably spend some time improving something.

6. The error log is gold.  Log everything.  Put in keys so it can be imported into a database and harvested for patterns.  Make your life easier. 

7. Catch your exception at the throw site. Handle it or format it for reporting.  Then either resume or throw it to the top level reporting handler.  This is easy for trivial size programs that can exit gracefully. Its a pain in the ass for large multifunction apps that have very complex state.  They should still be designed to have a thin shell (UI) that generates the state and serves as the catch layer for anything that is thrown from the depths. Where the state is trashed or becomes uncertain, the users should still be left with a UI that will allow them to re-try the same operation.  The program should not ghost out.

8. There should be layers of stability within the program.  The exception should unwind back to the previous layer of stability.  This layer should be in a known state and be immune to damage from the exception.  The User should then be able to move forward in the task again and test a different idea or variation without the whole program collapsing.

9. Wrap some protection around constructors and RAII style activity.  Be gentle when chaining constructors.  Have layers so that there is only one or two steps that unwind from a failed construction... not everything.
Give the user some levels of interaction (unless its a script driven or cmd line app obviously)  Let them find their way through the code and around the problems.