#if DEBUG
    // do some special code
#endif

Unity3D has a similar system. Mostly the docs (available here) seem to suggest this is for specialist code for different platforms: iPhone, Web, PC, etc. Thus the defined parameters are set in advance (e.g. UNITY_IPHONE). However, there is one that is useful for debugging, UNITY_EDITOR. This will only be set if the application is running inside the Unity3D GUI. Once you build the app those lines of code will be skipped. It can be used like the below example - very handy.

#if UNITY_EDITOR
    Debug.Log("Debugging");
#endif 

According to this Unity3D forum post it is also possible to define your own project specific preprocessor parameters.

SharpUnit works like a standard unit testing framework for C# code in Unity3D (although all output goes to the console, but that is fine for me). Although my work has largely been in UnityScript (Unity3D's JavaScript like language) and this didn't work so well due to issues with compilation order and SharpUnit's use of .Net custom attributes. After making the changes below, I found SharpUnit works well, and I'll probably be using it for my unit testing.

Unity3D compiles scripts in a set order (as described here). Thus if you have C# code that references a UnityScript class there can be a problem - although the reverse is not such an issue. When testing UnityScript with SharpUnit this means that the C# Unity3D_TestRunner class can be an issue. It references the TestCase classes, which I want to write in UnityScript. To do this I put the SharpUnit code in a folder under the Plugins top-level folder (the Standard Assets folder would have also worked). This means the SharpUnit code is compiled first. Then my tests went in a new folder together with a UnityScript rewrite of Unity3D_TestRunner, as shown below. This UnityScript TestRunner script is then attached to the TestRunner GameObject (in a special testing scene) rather than the C# version as described in the SharpUnit instructions.

#pragma strict

import SharpUnit;

function Start () {
	var suite: TestSuite = new TestSuite();
	suite.AddAll(DummyTest());
	var res: TestResult = suite.Run(null);
	var reporter: Unity3D_TestReporter = new Unity3D_TestReporter();
    reporter.LogResults(res);
}

Other possible solutions to this problem would be to just write my code in C# or to change SharpUnit to load TestCase classes dynamically at runtime. Rewriting the TestRunner seemed easiest.

The other problem encountered is that SharpUnit uses the C# custom attribute [UnitTest] to identify its test methods. The equivalent in UnityScript is a script directive (see the relevant section here). Thus @UnitTest needs to be placed at the top of each test function.

#pragma strict

import SharpUnit;

class DummyTest extends TestCase {

    var dummy: String;  

    /** Setup test resources, called before each test. */
    function SetUp() {
        dummy = "lkjkjh"; 
    }

    /** Dispose of test resources, called after each test */
    function TearDown() {
        dummy = null; 
    }

    /** Sample test that passes */
    @UnitTest
    function TestDummy_Pass() {
        Assert.NotNull(dummy);
    }

    /** Sample test that fails. */
    @UnitTest
    function TestDummy_Fail() {
        Assert.Null(dummy);
    }
}

A recent experiment of mine failed. I am writing a game with an online component and wanted the same code running on both the client and server - as this would reduce the chance of bugs. For ease of development Unity3D is being used for the client end, so the code there is either Javascript or C#. I have been writing Java servers professionally for years so it seemed silly not to use that knowledge. Clearly there is no common ground there. However, there is a project called Rhino to allow Javascript to run inside the Java JVM.

So can Javascript from Unity run in a Java environment? The short answer is "no", but the longer answer is "sometimes, with many caveats".

function square(i) {
	return i*i;
}

Context cx = Context.enter();
Scriptable scope = cx.initStandardObjects();
Function f1 = cx.compileFunction(scope, readFile("src/test_fn.js"), "<cmd>", 1, null);
System.out.println(f1.call(cx, scope, f1, new Object[] {5}));

Many people say that Javascript in Unity should more accurately be referred to as UnityScript. I think that is definitely true. Although it looks like Javascript there are some fundamental changes. Most importantly, Javascript uses a prototype-based scheme to define classes. UnityScript has an inheritance model, and the two schemes are not compatible. To me these differences are enough to prevent want I wanted to achieve.

Four of my old teams were shutdown with near total loss of code. Another two years were spent at a consulting firm where most of the clients I serviced no longer exist. Those 5 jobs combined mean that half of my working life's production is largely gone. At a guess I would say 10% of the code from my first five working years is still used; around 30% from the second five years; and, over two-thirds of the last 5 years of my code is currently running. My professional code appears to have a half-life of around 4 years. This sounds about right considering the rate of technology change.

If the line was intersecting an object in the scene then this could be easily achieved with Unity3D's built in functions. In this case by casting a ray from the camera and finding the objects it hits (see the Raycast help page). However, my prototype is set in space, there is no object there to hit other than a small spaceship.

var s = camera.ScreenToWorldPoint(Vector3(Input.mousePosition.x, Input.mousePosition.y, 100.0)); 

[c.x + (m.x - c.x) * t, c.y + (m.y - c.y) * t, c.z + (m.z - c.z) * t]

y = spaceship.y

spaceship.y = c.y + (m.y - c.y) * t

if (m.y == c.y) {
   t = 0; // no intersection
} else {
   t = (spaceship.y - c.y) / (m.y - c.y); 
}

This is a series of talks and interviews from the La Trobe University Archaeology department. The topics vary wildly, from the traditional Ancient Egypt and Cyprus, to relatively modern digs in Melbourne city (founded in 1835). As the series is archaeologically focussed there is more emphasis on the extraction and identification of objects than history. At present there are 12 episodes - 2 are short videos (around 3 minutes) and the remainder are audio only. Two of the audio podcasts are hour long scholarly presentations, while the other 8 are interviews of between 15 to 20 minutes duration. There may be more episodes in the series as the entries so far have trickled in over the last 2 years. Production quality is high for the whole series.

There are two podcasts on archaeology in Oceania, particularly Hawaii. One is an academic presentation, while the other is an interview with the same presenter on the same topic. There is some talk on Jared Diamond's Collapse book. Diamond suggests that society on the Polynesian island Mangareva due to overforestation. However, the presenter's research suggests instead that the deforestation was caused by a lack of phosphorus in the soil due to the killing of sea birds. The discussion of Hawaii is similarly focussed on the affect of intensive cultivation on soil quality. Unsurprisingly the indigenous people started agriculture on the best land and as population grew, expanded out to less productive land. Once all arable areas were cultivated, the land became more subdivided and population growth slowed. Also there is evidence of political consolidation beginning around the same time.

Another paired presentation and interview discuss excavations at the ancient Egyptian capital Amarna. They are focussed on the industry of the time - in particular small metal work and glazed pottery. Details of the materials used are probed with synchrotrons and a bit of experimental archaeology is conducted to determine the techniques used to manufacture them.

Another episode details the search for ships lost in Vietnam by the Chinese emperor Kublai Khan at the Battle of Bach Dang. Three episodes (including both video podcasts) discuss the tools and evolution of early humans, especially the position in the evolutionary tree of some complete skeletons recently found in Sediba. There is also an interview about bronze age burials in Cyprus and other podcasts focus on the archaeological difficulties and discoveries underwater or in cities.

I often find myself writing time-based caches. Something like storing the last X hours of ticks from a data feed. Most teams I join usually have a utility class to help with such tasks. In a recent move I joined a team that didn't have such a utility, but did have a need for such a cache. Before coding, I thought I do a quick check to see if anything new had come along to help. At this point I discovered the Java 6 NavigableMap interface.

NavigableMap defines a type of sorted map with handy methods for obtaining submaps. So to get a map of the entries greater than a particular value use the tailMap method. The corresponding method for the submap less than a value is headMap. These methods return a view on the original map. So changes to the submap are reflected in the original map. The JDK provides concurrent and non-concurrent implementations of the interface.

This is very useful for a time-based cache. Create a NavigableMap sorted on the time (I used the epoch milliseconds returned by System.currentTimeMillis()) then tailMap returns the entries younger than a given time, and headMap those older. So to trim the cache of entries older than a certain time use headMap(System.currentTimeMillis() - maxAge).clear(). So easy!

Here is a complete time-based cache class for use as an example.

public class TimeSeriesCache<V> {

    private static final int MILLIS_IN_MINUTE = 60 * 1000;
    private static final int CLEAR_OLD_PERIOD_MINUTES = 1;

    private final NavigableMap<Long, V> series = new ConcurrentSkipListMap<Long, V>();
    private final Set<TickListener<K, Long, V>> subscribers;

    public TimeSeriesCache(int maxAgeMinutes) {
        if (maxAgeMinutes > 0) {
            final int maxAge = maxAgeMinutes * MILLIS_IN_MINUTE;
            Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(
                    new Runnable() {
                        @SuppressWarnings("boxing")
                        @Override public void run() {
                            series.headMap(System.currentTimeMillis() - maxAge).clear();

                        }
                    }, CLEAR_OLD_PERIOD_MINUTES, CLEAR_OLD_PERIOD_MINUTES, TimeUnit.MINUTES);
        }
    }

    public Collection<V> getSeriesAfter(Long fromTimestamp) {
        return series.tailMap(fromTimestamp).values();
    }

    public void add(V value) {
        series.put(System.currentTimeMillis(), value);
    }

    public void add(Long timestamp, V value) {
        series.put(timestamp, value);
    }
}

First up I played Call Of Duty 4: Modern Warfare, the original 2007 Modern Warfare game which spawned the incredibly popular series of first-person shooters of the same name. At first I was impressed with the intensity of this game. However, the fast pace quickly slows with realisation there is essentially no penalty to getting shot. Death is a mere slight pause. I felt like I was on rails, being led through the action. The game was just a reaction speed test. Multiplayer is probably better, but I didn't play that - I doubt my reactions are fast enough. The story is ok, nothing special. Although I did detect a possible subtle satire on war - but that could just be me. The story is most notable for a couple of impressive famous scenes (the nuke level and the gunship level) that do work very well. This game is probably too linear and twitchy for me.

Next up I played Assasins Creed: Brotherhood. I was particularly looking forward to this game because of its open world setting in medieval Rome. Certainly the graphics are beautiful and I enjoyed wandering around the ruins of Rome. But the controls! This game was incredibly frustrating - it was hard to get my avatar to perform as intended. I tried for many hours (28 total), but still found myself often shouting at the computer and cursing the clumsy controls. Eventually I just raced to finish the main story. Incidently, the story is very silly and not worth discussing. This game could have been so much better, but is just annoying.

Just a few days ago I completed Bioshock. This is an excellent game, restoring my belief in modern gaming after the previous two disappointments. The Ayn Rand-gone-wild underwater setting is incredible. The art-deco and slightly cartoony (but I think that was the point) graphics are decent. I often found myself just walking around looking at the banners and architecture. Most importantly the controls were super smooth. The game was also quite intense, particularly at the start and end. Sometimes I jumped at a surprising action or went looking for someone I could hear nearby. It is interesting that both this game and Mass Effect 2, give the player some small choices that make minor differences to gameplay, as opposed to the lack of agency in Modern Warfare. A little choice (even if it is fairly inconsequential in plot terms) goes a long way in making the player feel involved.

The interview process was the most arduous I've ever encountered. First there was an interview by a couple of managers. Then another interview by the entire team I would be joining. A panel of nine people arrayed in front on me. During this part they asked me to give an impromptu 15 minute presentation of my ex-PhD topic. A quizzing on its practical applicability followed. By this stage I have been onsite two hours and they said it was time for the next stage. I was taxied into the city and given a battery of psychometric tests. There was a logical reasoning test (well-above average), vocabulary test (average), Myers-Briggs test (INTP, as always) and another test I'd never heard of before to check my work aptitude. Nearly 5 hours in total and I was completely drained.

I got the job and after a few months I heard that it didn't really matter what the tests said. Half the team (including the manager) knew me from uni or honours, so unless I had a breakdown the job was always mine. To prove the point I was told the results of the psychometric tests. Apparently the unknown test had indicated I was completely unemployable and unable to work in a team. They ignored it and hired me anyway.

The Rio Tinto R&TD team in Perth was in beautiful purpose built building near Curtin University. It was designed to be like a village - a central street walkway acting as a street with trees and benches (all inside). Off the walkway came the open plan office space. There was also a large reception, board room, library, large eating area and kitchen. No canteen, but I never heard of anyone in Perth having a canteen. It was set on landscaped grounds with more than enough parking and there was tons of natural light. A very pleasant workspace. The only problem was the abandoned building and the emptiness.

The complex was built to house over 300 staff, but never housed more than 55 people while I was there. There was another entire building with workshops unused and locked up. Most of my colleagues spread themselves out over 2 desks. A couple of months before I started there was over 200 people on site. Most desks were taken and the workshops full of engineers. However, many were made redundant or transferred around the time of my interview. Four small teams were left (plus admin staff).

I was in Knowledge-Based Systems. We were supposed to focus on applying machine learning techniques (like expert systems) to mining problems. Although most of our time was spent writing mine simulations, linear optimisation systems (basically the simplex method with a large number of variables and a nice GUI) or training tools. There was another team of more "practical" software developers working with early web technologies. On the non-computer side was a team of mathematicians and engineers doing various consulting tasks and a small team focused on Computational Fluid Dynamics in smelters.

With just 1st class Honours I was clearly one of the least educated people in the building. Their was a distinct academic bias. Most of the senior managers had PhDs, as did probably a third of the staff. People generally had time to think - although that may not have been a good indicator for future prospects. There were often discussions of very scientific topics and opinions were always well informed. Here I learnt the more theoretical side of software engineering with regular arguments on what process or pattern was best in a certain situation. Later I learnt the more practical side.

While I was there the place had an eerie atmosphere. All non-managers openly believed that we would all be made redundant sooner rather than later. Everyone knew the intimate details of the redundancy policy. It was very generous so staff turnover was low as people waited for their inevitable payout. I remember hearing a couple of anonymous shouts of "make me redundant now!". There was a bit of black humour around the situation. When the head of the global technology division changed we joked about him being an evil leprechaun (he had an unfortunate staff photo) who would sack us all. We were right!

The site was also extremely safe. All sites in Rio Tinto apparently followed the same safety precautions. Thus our research office building took safety as seriously as a mine site. There was a sign at the entrance proudly displaying there there had been no lost time due to injury for over 600 days (not sure the actual number, but it was years). Towards the end of my time there the counter reset after a morning was lost when a minor traffic accident resulted in a checkup at the doctors (they were fine). We had a safety manager who trained us all on the safety precautions. Every month he would tour the site for safety violations and hand out cautions - normally for overly large stacks of paper or dirty mugs. I felt a little sorry for the guy, there wasn't much for him to do. He previously had a similar job at a mine, which must have been much more interesting. Although it was impressive how after I casually mentioned my fingers ached a little one day to see how serious it was taken. I was visited by an outside ergonomics expert who recommended my desk be lowered a few centimeters. That afternoon it was dismantled and rebuilt! The expert was right, the new desk was much better.

I sat with two colleagues is a small area of desks partitioned off between a reception desk and the General Manager's office. The area was partitioned into thirds, each section with 2 desks, 2 PCs, etc. We took one section each. It was a good little spot. The partitions went up to eye level, and there was only one place to enter the area. The partitions were also setup such that to reach the back thirds a visitor would need to make a couple of 90 degree turns. Furthermore large pot plants had been placed at strategic points to block sightlines into the area. The basic affect was that we could tell when someone was coming towards us, but they couldn't see what we were doing. Knowing the person who sat furthest from the entrance (an aspiring DJ), I don't think this setup was unintentional. For the same reason none of the three of us could see eachothers' screens. I had two PCs, but only ever used one, a decent second hand computer (from someone recently made redundant - Pentium2 with a 17" CRT, good for the late 90's). One of the other guys had 2 PCs and bright blue Silicon Graphics Indigo machine for a 3D modelling project he did - very cool.

As a small office in a global company we traveled often to various mining sites around the world. I only went once, to an Australian gold mine, which I will write about later. Others went around the world. The one place I would have like to have visited was the Grasberg mine in Indonesia - a very large gold and copper mine up a tropical mountain. There was some talk of sending me there to run a training course, but I didn't act keen and the timing wasn't good with my other projects. In retrospect I should have volunteered. Irian Jaya is a place that most foreigners (or even Indonesians) do not get a chance to visit. There were always good stories about visits. During the Asian financial crisis in 1997 one colleague visiting there managed to run up an enormous 5 digit expenses bill - he occasionally told snippets of the story of his few days living the high life. Management were aghast, but I had the sense they were slightly impressed with the ability to spend so much when the local currency was so cheap.

Soon after I declined the trip to Grasberg one of our staff visiting the mine was threatened with a spear when some locals bust into the onsite offices. I think it turned out to be a dispute over a pig, but management was greatly concerned as there is a low-level insurgency in the area (over independence from Indonesia). No one from our office ever went there again.

Working at R&TD was fairly pleasant on a day-to-day basis. It was small enough for us all know eachother, and there was a slight siege mentality - us versus the off-site management wanting to shut us down. Everyone got a mug with their name (or nickname) printed on it when they started work. This stopped the problem everywhere else about disappearing mugs/cups. I still have mine 12 years later. When an eclipse occurred we all headed outside for the afternoon to see it. There was a social committee which arranged various regular small events. I was actually a member or the committee for a while. I arranged the Christmas Party river cruise right before I left. In fact I didn't go to the party I organised, it didn't seem right as I quit and left a few weeks before the event.

I also tried to get involved in the company superannuation/pension plan. They had elections for staff representatives on the plan's board. I thought it would look good on my resume. Most of the people I worked with acted bemused when told I was running. My campaign was fairly weak, consisting mainly of writing a blurb for the company magazine (As did all the other candidates). In the end I think I got about 20 votes, not even half the people I worked with. The winners got thousands of votes.

After I had been at Rio just over a year, the work starting slowing, senior management swapped jobs and a review was announced. It seemed like the end was nigh. I knew the redundancy policy very well (as did everyone) and until I had been there over two years I would receive very little. It seemed unlikely I would make it that far or be promoted. It is best to jump than be pushed so I looked around. Finding a job in the dotcom boom was not too hard, and I left after 18 months at Rio. A few months later all but a handful of my ex-colleagues were sacked and the facility shuttered. My timing was just right.

My last memories of working at Rio were having competitions with the aspiring DJ next to me over who could leave earliest. He won by leaving at 3pm, walking past the General Managers office and saying goodbye before walking out. I didn't have the balls to top that even though I had quit. On my last day we all went to the pub for lunch. I left about 4pm, my manager and most of his team were still there (and stayed late into the night). He teased me for leaving "early".

Continued with details of the tasks I performed while at Rio Tinto.

After writing 6 long posts on my experiences in EGB IT, I realised I still missed out many points. Here they are in no particular order.

So after nearly 7 years on EGB technology teams I have moved on. Not out of banking (at least not yet), but when the opportunity came to try a different business area I jumped. This is despite being able to earn more money if I stayed in my EGB niche. There are two related reasons for leaving: the industry and technology are both changing to the detriment of developers.

When I started in 2005, EGB trading was already on an upswing that lasted through 2009. I'm not sure when this upwards trajectory began, but the people around me considered it normal. Business was good throughout the mortgage and banking crisis of 2008. When times are good and the desks are making good money some of it is reinvested into technology. There was a lot of optimism and this translated into banks wanting the fastest and smartest trading platform. We got to rewrite systems. Increasingly business was relying on technology - it was becoming trade-by-wire. It seemed that there was much further to go. Algorithmic trading is big in equities, why couldn't it be big in fixed income too. There was huge potential for writing interesting code.

This environment no longer exists. It was only when the European debt crisis began to bite in 2011 that things trended downwards, but then they went down fast. There is a great deal less ambition among the fixed income desks. Most traders seem happy just to not be losing money - something many are not achieving. Some banks are shutting down their bonds desks. As a natural consequence there is less to spend on technology and little desire to do more than maintenance. Flow volume is king, and as far as technology development is concerned, that is not hard. Thus less developers are required and the work is less interesting.

Combined with this is the creeping commoditisation of bonds technology. When I started Ion provided mainly gateways, little tools and their message bus. Over time they have climbed up the product stack. Now they also sell pricing engines, autoquoters, autohedgers, risk engines, position servers - nearly everything a bank needs to trade cash bonds. The quality is fine too. Their applications won't do everything a desk requires, but it will do most of it and the desk's technology team can add the remainder quickly. Not all banks will use vendor systems (many don't like Ion or see advantage in bespoke systems), but enough will to affect the market for EGB technologists.

Thus, once again, less developers are required and the work is less interesting. I don't see the situation changing until the market improves - and I don't see that happening soon. So I thought it time to try a different business area.