Wednesday, November 28, 2012

Rules for Art Nouveau

I like figuring out algorithmic rules for particular genre's of art and architecture. 

Art Nouveau - This was a style that arose as a reaction to Academic Art.  If you wish to understand why Art Nouveau seems to break so many rules (while still providing evidence of being fully aware of them) have a look at how rigorously the rules were emphasised in Academic Art.  Think of Academic Art as a "Street Art" style that arose from Academy trained artists wanting to express themselves differently but not being able to forget all the rules they had already learned.

So  my "rules" for Art Nouveau are:

2.5 dimensions.  This means that the image is composed of discreet "layers" which do not obey the same coherent rules of persective or foreshortening.  Each Layer can include these elements but they are not "simulating" depth.  Z order is essential but needs to be "played" with to create a wholeistic composition.

Establish borders and framing then break it.  One of the essential elements in this style is the breaking of the frame.  This creates the entertaining "flow" between the layers and binds the whole image together.

Use frames and borders to "punch through" and combine layers.  This technique also creates links betwen the layers and creates relationships.  This compensates for the lack of relationships that would otherwise be created by the rules of depth and helps with the Mise-en-scene of the content elements.

Contrast between geometric repetition and organic repetition.  These should be similar scale to help re-inforce the juxtaposition of the two different styles.  For example the conrtast between a repeating geomtric motif and a group of  flowers or butterflies.

Similarity rather than symetry.  Elements are often "similar" in that they occupy symetrical areas on the composition but are not "mirror" images.  This plays with the concept of geomtric symetry, showing that the artist is aware of the rules but has chosen to be "playful" with them.

Dynamic lines work and outlines. The hand inked style of the line work and the heavy outline styles are characteristic of the materials and the media that the early work was build with.  This has come to be part of the "signature" of the graphic design work.  (Obviously not a factor in the Architectural works)

Curves.  The convention of never quite having a straight line is one of those rule-of-thumb that the artists "play" with.  I think its the contrast between the curves and the lines that make for the playful nature while still being "constrained".  The curves tend to be flowing lines and "spline" type curves rather than crazy scribble type lines.  They are very dynamic and directed.

Content.  The style draws in and often contrasts geomtric motifs and styalised nature. Figures and objects are often posed together with the figures being displayed in "static" poses with dynamic elements such as hair and drapes shown blowing styalistically in the breeze.

Shading and textures.  The use of flat colour to create obviously simple shading and "hand painted" style shading contrasts with true shaded gradients creates an interesting juxtaposition of textures.  This can be a subtle effect.  Generally each layer has its own "style" of shading which is consistent through the layer.  Soft washes and out of focus forms are often layered in the background.

Thursday, November 22, 2012

Neural Plasticity and Brain Training Resources collection

One case study that I have not seen clearly connected to the topic of Neural Plasticity is that of the London Cab drivers. 

London Cabbies undergo a legendary training that involves memorising huge amounts of map data and street names.  I remember someone in an interview on tv once saying that someone had used MRI to show that there were changes in the drivers brains after this training process was complete.  Tada!  NP at work.

Brain Fitness (Limit to systems that have some lonitudinal data collection and analysis function, not just games that exercise the brain)

Clinical ???



Catholic Schools Trial of the Arrowsmith Program

Other Programs

 News Site


Wednesday, November 21, 2012

Depth of Programming Tools

Being a spectator to the on-going mess that is the microsoft developer roadmap... (would train wreck be too strong?) and reading this post on Rx.  It got me thinking about some of the obvious and in-obvious side effects of the endless churn in the Microsoft eccosystem.

* Developers Inability to Commit to a Technolgy
* Third party tools vendors and Extenders lack of commitment
* Consumers lack of clarity on the right technology for their projects

All this is pretty obvious and well blogged about.  The thought tha occured to me is that the endless renewal of technologies creates a very "superficial" eccosystem.  No-one has the time or the energy to create deep paradigm shifting technologies on top of any of these languages or stacks becase it takes some years of experience and a subtle understanding of the problem space before these kinds of solutions can emerge and be polished.

The above ideas around Rx are drawn from problems with their roots all the way back in the early days of event driven programming, but more recently it draws in concepts from LINQ and other agile data access models.  These have all taken time to stew and have been applied to .NET... but now with the maturing of the library .NET has past its prime.  It's no longer the kid that is getting all the attention.

Looking at the other Microsoft babies of recent years, SilverLight, XAML, WPF et. al. there has not been enough time for anyone to live with them and start to see solutions to the deep problems.   So there is only a superficial set of tools and technologies to work with them... and then they are gone.

I think this becomes a self-reinforcing cycle.  Microsoft presents uncertainty and doubt about the tools, developers don't commit to the tools,   Microsoft panics and creates new tools with even less certainty and more doubt.

The IT lecturers must be totally pissed off.  I remember only a couple of years ago when they finally let go of C++ and upgraded all the courseware to C# and XAML.  To have to again totally re-build their course material and test drive it over a couple of years to get it all sorted out will completely piss them off.  No wonder book publishers are doing quick and dirty publishing for MS products.  There is just no time to get deep with anything.

Anyway, the takeaway is that its the lack of really deep and clever extensions to languages that I feel will be the biggest and most costly loss.  These are the tools that provide the biggest bang for their buck and help move whole industries forward.  We don't need yet another language or GUI toolkit.  We need deep problem solving libraries with thought, well designed API's that have had time and bright minds shape them. We need comprehensive tool chains that are bedded down and have all the subtle features and bugs sorted.  This is just not happening on the MS stacks at the moment.

VS2012 is the epitomy of Q&D.  There is all sorts of stuff missing or "just" working.  It smells of panic. It also smells of trying to put a little something for everyone across a fragmented ecosystem of different technologies.  Imagine if all the effort were spent on getting just a few technologies really right.  The fact that this has not happened probably points to the fact that any one technology is not a compelling difference anymore.  Great support for a language is not a "killer app", so now its good enough to just have "just enough" support to tick the box.

Welcome to the world of increasingly sucky tools from MS.

Monday, November 19, 2012

Unit Testing to find bugs???

I just read the above article and a couple of the comments.  The author seems to think that Unit Tests have something to do with finding bugs.

What bugs? Unit testing cannot "find" bugs.  A developer can use Unit tests to detect violations of expected behaviour (assuming those unit tests exist).  Bugs are conceptual issues that may exist in the developesr expected functionality, the users expected functionality, unexpected functionality, future functionality... etc.  

1) Unit Tests can be used to verify that a piece of code "does what it is designed to do".  I.e, that it has the expected behaviour or functionality as the designer understands it.

2) Unit Tests can't verify that code "does other things that it was not designed to do" as this is an open ended list.  Simple design, encapsulation and composition are better tools to manage this kind of complexity.

3) Unit Tests can be used to verify that code "does not do a specific thing that it was designed not to do" but only once the designer/developer knows enough about the undesirable behaviour to write a specific test for it.  This then becomes an instance of the first clause above.  However, it does not guarantee that this behaviour cannot occur in an unexpected way.  It can only verify that the behaviour does not occur in the way expected by the test. 

A developer can use a Unit Test to assert something explicitly about the behaviour of a unit of code and then Verify that Assertion now and in the future.

A developer cannot use Unit Tests to infer something about the behaviour of the code. (Well they could, but it will bite them sooner or later)

A Unit Test is an attempt to treat a piece of code as a deterministic machine.

Sample Data In - > Code Under Test -> Expected Behaviour Out.

This system involves no variables.  It's a simple mapping from the input to the output. It has no state except what you inflict on it. This is all a Unit Test can be.  Even if you get clever and provide an exhaustive list of sample data and run it all through the code, its still the same case.  You cannot assert anything about the behaviour of the code except under the conditions you have tested.  You can infer about the behaviour of the code under conditions you have not tested... but its guessing.  Not even educated guessing. Certainly not SWAG.  It's just WAG.

You CANNOT predict all the conditions that the code could, should, might, maybe run under, now or in the future.  You can't come close to guessing what tiny modifications might be done to the code... you can't know if that code will be transcoded to another system, language or hardware platform.... it may be compiled, cross-compiled, JIT compiled, interpretted, it might be "optimised" by hand or tool... you code can be so thoughly changed that you can not reason about it.  The language standard could evolve, your code could be compiled by better or worse tools, linted, scrubbed, re-ordered, have other code injected, be mutated at runtime, suffer a stack fault, have its memory corrupted.... malware may interfere, API's change, security software not even invented yet may completely stuff it up.  Its even possible that your code could run in a Virtual Machine or some other system that allows pause and restart.  You code could have its state saved and reloaded or modified and reloaded... or reloaded on a completely different machine in a cluster... or a different data center on a different continent..  there is just nothing that cannot be munged up given the wrong scenario. 

But in every case above, you can still assert intended behaviour and verify if the code satisifes that assertion or not.

Just for fun, imagine the worse possible scenario for the piece of code that you can, combining all the worst bits above. 

The Code is compiled to intermiary bytecode using a compiler you have never seen, run on a custom VM, split across unsyncronised virtual threads, saved and reloaded with different time clocks on different hardware, then recompiled using a JIT to machine code, is reordered to optimise it to run on a different hardware architecture, then the threads are stopped and started a couple of times just for fun.... then its all brought back together, the results are rounded, types are dynamically converted and the results passed through a couple of API's using subtly different type sizes (say, Lua binding then through a C# wrapper and back to some native C++ and out to a Python script) before being thrown against the wall, wrapped into JSON and passed to a grafted-on GUI running a mixture of Javascript, ASP and Actionscript....on an old handheld game console that has been jail-broken and has an emulator running a stripped down version of  Windows 95 a 1/10 expected clock speed and a hand patched copy of IE6 ... and enough Malware to make your eyes bleed.

Can you verify that the code does not do anything that it should not?  Can you find "Bugs" using a Unit Test in this scenario?  Can you even guess what a "bug" might be in this scenario?  The only thing you can do is test for expected functionality and verify if it exists or not. 

Welcome to Unit Testing.

My Wish list for Agent based simulation engine

After looking at a bunch of sim engines and finding a real mix of features, the stuff I am looking for is:

In World Features

  • Define the world and its properties (As an agent or as a special "super agent"... I don't care)
  • Define the agent(s) and their properties (Deterministic, GA, Evolvable code, Neural Nets whatever)
  • Define framework/helper agents
    • Broadcast and narrowcast communication to groups, channels, layers etc
    • Transport systems and constraints  (Simulate natural or man-made systems to externally affect agents movment) 
    • Grouping Agents for efficient manipulation of agents (group, list, collection, ripple group, proximity group, ray strip, chain, sequence etc)
    • Network structures with relationship sub-elements
  •  Listener, observer, subscribe kind of models for composition of arbitrary relationships between agents

Out of World Features

  •  Graphical Interface (Realtime or not... but must have) display, record video, snapshots, timelapse camera.  World camers, tracking camera for agents. Layers that can be turned on and off.  Stats windows for watching variables.
  • Run Control (Play, Pause, Various speed steps, Stop/End/Terminate)
  • Multi-Dish - I want to be able to run multiple sims with a synchronised time clock side by side with a master run controls to run,pause,stop them all.
  • Rewind (would be nice but I understand why it would be difficult/impossible in many cases for efficiency) This would be nice even if it was just the ability to take a state snapshot every X time-steps and the roll back to an arbitrary time step.
  • Explainer, debugger system for analysis of a running sim down to the finest grain agent level.
  • Data output pipeline to one or more files and to the network in some fashion
  • Networkability (nice to have for bigger sims but not needed for small stuff) some listener interface and talker interface with some simple distributed topology and a master agregator unit.
  • Trace and Probe model for analysis of any and all agents in the system. This should allow arbitrary attach and detach during a running simulation.  This should also allow setting of agent variables and snapshoting agents state. It would be good to be able to snapshot an agent and "inject" that snapshot back into the agent or another agent.

Platform Features

 I don't really care... but it has to be able to be scripted and extended.  It would be nice if it runs on windows but I can adapt to anything except OSX.  Simply because the Uni is anti-mac this year.

I would prefer a clean codebase that can be compiled using industry standard tools (C++, C# VB, Java, Python) rather than one of the less popular languages or niche languages.  The absence of years of cruft would be really appreciated.

For a scripting language, it would be preferable to have something popular and accessible rather than yet another domain specific langauge just because someone wanted to write their own procedural language.  I understand creating a language for something like evolutionary computing or something like GA's but not for straight OO procedural scripting.  Use python, Lua or one of the dynamic Java dialects.  Something with a very well developed set of language tools.  A .NET

Sunday, November 18, 2012

Is the SIR model applicable for Zombie outbreaks?

I have been playing with SimZombie and thinking about the paper "When Zombies attack! Mathmatical modelling of an outbreak of Zombie Infection" (Availible here).  Both are based on the SIR model using a synchronous latice from epidemiology and I think the model is way too simple to be useful.

My problem is that humans in a population do not act like cells or cattle.  There are plenty of similarities but its the differences that break the model fundamentally. However, like all thought experiments on imaginary ailments... this is simply a case of my imagination against someone elses...

The problem is that the variables in the SIR model is very simplistic.

Transition from the S to the I state is inevitable goverened only by some probability at each possible infection event.  Similarly transition from the I to the R state is also inevitable, again regulated by some probability.

The argument being that the complexity of the system is stripped down and the value of the model is in the understanding of the outcomes given different starting conditions of the variables. 

However, I would contend that stripping the population down to such an abstraction, produces a model that is pointlessly simple and, to be honest, boring.  I mean, if you are going to spend the time to model an imaginary disease, you may as well enjoy it.

So where to begin?  Well let's start by extenting the SIR model a little.

Lets start by looking at a more interesting number of compartments in the model.

S - Succeptable ( This is the "living" population in most scenarios)
B - Bitten (Early stage Infection, but not mentally compromised ...yet)
Z - Zombie (Fully infected classical Zombie. )
D - Dead (This is permaently dead... not undead-dead.  This is game-over)

Finally, the most important divergence from the SIR model is the concept that the population is passive. I propose that we add another compartment.

H - Zombie Hunter

I propose that we accept that a certain proportion of the population are not going to be particularly "passive" and will take some steps to at least defend themselves, while others will go to the extreem of purposefully hunting down Zombies.

One of the interesting things is this proposed model is how these hunters will behave over time.  If we consider that someone learning to hunt, should improve with experience (learn) then they should become more effective given time.  While the other side of this coin may be a resource problem. If they run out of energy or ammo... then they may become less effective over time. 

We can still map out the state transition diagram. I think its pretty obvious.
S->B   (Got bitten)
S->D   (Got dead)
S->H   (Got angry)

B->Z   (Full blown infection)
B->D   (Got dead. Self inflicted, friends, treage )

H->S   (Calmed down or out of ammo)
H->B   (Got bitten)
H->D   (Got dead)

Z->D   (Got dead)

The question is always... "is there a cure"?  If there is a state transition from Z to S then does it grant immunity or is the individual again succeptable, if not, there would be a true "R" state with immunity.

Anyway, lets have a look at some of the potential variables for the different compartments.

S Compartment
* Movement rate
* Intelligence
* Clustering and Cooperation
* Communication

B Compartment
* Time to full blown infection
* Knowledge of process
* Willingness to self-terminate
* Willingness to hunt full blown Zombies

Z Compartment
* Movment rate of a Zombie
* Intelligence of the Zombie
* "Hunger" rate of the Zombie
* Infection from contact/bite
* Shelf-life.  (How long can a Zombie last without food? Is a Zombie Omnivourous? Does a Zombie die of old age? Can a Zombie die from other things? Does a Zombie "fall apart" from wear and tear?)

D Compartment
Apart from being really really dead, are these agents:

* Still infectious?
* A short or long term food source for the Zombies
* Going to drive the behaviour of either the S, B, Z or H compartments

H Compartment
* Experience
* Resources
* Movment
* Intelligence
* Cooperation
* Reproduction ( can a H turn an S into a H?)

Now this should make for an interesting model. 

I think the general reason that Zombies are so fearsome in all the scenarios is that they are implicitly or explicity given immortality and a reasonable amount of intelligence but not enough to be able to survive.  It would be pointless to debate these issues in the context of arguing about an infection model because the assumption is that Zombies have some sort of human seeking drive that makes living people their only food source.  In the event that this was true, the logical extensions of become fairly idiotic.  Are Zombies cold blooded?  If not, how do they maintain their energy needs?  Anyway... at some point they will run out of energy and then what? If they can eat something else... then why bother with humans who can be a bit hard to catch? As I said, unless you accept some of these assumptions, the whole game falls apart.


* Zombie are essentially "Immortal" and do not "die" from anything like disease, decomposition or wear-and-tear.
* Zombies are fixated on fresh humans ( cause the script writer told them too...)
* Zombies are fairly dumb, cannot communicate directly and engage in only basic food aquisition and movment. Essentially they act "alone".
* There is no cure... or the infection process is so destructive there is "nothing left tosave"... so for practical purposes its a one way trip.

The assumption that Zombies are Immortal is problematic because it creates a cascade effect of an increasingly large population of Zombies.  In the event that this is "valid" within the scenario, then it does present a challenge for the uninfected.  In the event that there is some "decay" model for the Zombies then there would need to be some effect of time on the population of the Zombies.  In this case the obvious strategy for the uninfected is to quarantine themselves or the infected and wait it out.  The fact that most of the popular fiction around Zombies tends to work in a timeframe where any decay model is not a significant factor means that this is not well explored. (28 weeks Later looked at this "wait it out" model and explored the concept of latent infection "flaring up" again.)

The assumption that Zombies are fixated on fresh meat presents a few problems.  While it would probably be fairly easy to access in the early days of an "outbreak" due to the suprise factor. I think that as soon as the knowledge about the outbreak was "released" the availible population of food would disperse and be more cautious.  This would reduce the growth rate of the Zombie population simply because the availible population of uninfected were aware and attempting to avoid the Zombies.  The other problem is that if a mob of Zombies catch up with a food source, they will probably consume it rather than simply infecting it.  So the rate at which contact with Zombies leads to infection rather than death would probably be related to the densitie of Zombies in the immediate area. The other question is how long does it take for a corpse to become unattactive to Zombies as a food source?  Would there be a period where a freshly infected Zombie was still "tasty" enough that other Zombies would try to "snack" on each other?  In this case, would they try to defend themselves?  I which case can you get Zombies to fight each other?  Will they fight to the death?  Are Zombies smart enough to distinguish between a Zombie that is covered in fresh blood from feeding vs one that is still fresh enough to snack on?  This does suggest some fairly advanced reasoning and sensing ability.    

The assumption that Zombies act alone is interesting. In most popular culture Zombie outbreaks Zombie populations display emergent flocking behaviour which makes the danger from a single Zombie much more dangerous.  For this behaviour to function, Zombies must be able to perceive each other and attribute meaning to others behaviour.  This could function simply by Zombies "walking" purposfully when they are on the trail of food, and walking differently when they are "wandering".  So any Zombie in "wander" mode who sees another Zombie walking in "pursuit" mode will perceive that they are heading toward food and join in.  The key being that the zombie joining the "pursuit" must then change their behaviour to "pursuit" mode as well.

This "model" creates an indirect system of emergent communication within the population of Zombies.   The result is that Zombies follow other Zombies and engage in "mobbing" behaviour of "food sources".   The question is why a Zombie, who can figure out the difference between another Zombie randomly walking and the same Zombie walking toward food does not use their perceptions for other cognitive functions... just imagine Zombies with Neural Plasticity....

Anyway, the obvious problem with a flocking algorithm that is based on its members following each other is that potentially it can create a "whirlpool" of Zombies following Zombies following the first Zombies.  This whirlpool could potentially grow to suck in all the Zombies in the world.  Assuming that none of the un-infected are stupid enough to disturb the whirlpool, this would keep all the Zombies occupied until they "timed out". 

As I mentioned above, if you follow some of these assumptions they become silly. 


Thursday, November 15, 2012

Agent Based Simulation Engines

COS Sim - Traffic flow simulation

SimZombie - This looks like fun

XMLisp - Seems like a simulation toolkit or a simple game engine.

MASON - This one looks quite well developed.

RePast - Looks well developed and flexible.

This is yet another Java based engine for doing 2d simple agents in a simple world.  This is even more rigid as it uses a latice world.

Objective-C.... mmmk.  Reading the ideas page gives you a bit of an idea of the amount of baggage that this system is dragging around with it.  It looks like a very nice package but its got bloat and is trying to be all sorts of things to too many people.  I think once you spilt your efforts across one or more languages... its all over... the efforts of the community get sucked up by having to duplicate everything and trying to support new work with a foot on both sides of the langauge barrier.  It just buries the pace of evolution. I think rob the system for all the good ideas and start again clean.  .NET across Mono is probably the easy solution with some front end work done in HTML5 for simple cross platform support.

This looks like a nice little package. Fast and easy to set up with a good graphics engine already in place. Has a good set of docs and examples.  Spot the teaching tool. I could do some things with this.  There is some framework already in place but some you would need to implement.  Have not looked at the source yet.

The Mega List of Agent Modelling Software

Examination of the SimZombie system and the sample scenarios

This is a straight forward 2d sandbox model world with interacting agents.  There is no physical collision between models so there is visual overlap and no deflection of paths.   There are no obvious "edge" effects around the walls of the sandbox, so make of that what you will. The walls are simply movement constraints.
The number of agents seems fixed and the state transitions are pretty obvious.  Its just a complex way to do deterministic modelling with a basic visualisation engine.  The scenarios seem to be straight forward SIR models (although one has four states just for variety. It's a short transition state so doesn't fundamentally change the model except cosmetically.)

The environment is Java, so while its all cross platform and stuff, it carries the curse of installing Java and suffering all the security side effects that come with it.  Yuck.

Zombie Scenario (Successful Defensive)

Zombie (Successful Defensive) Scenario Description

A sample zombie simulation where the susceptibles are capable of fighting back the zombies once awareness is raised.

Thoughts on the Zombie (Successful Defensive) Scenario

This scenario uses  Suceptable (S) as green, Infected (I) as red and something else as light blue.  I guess this is "dead" as a Zombie or a green can transform into a blue. We will call this the (R) state.

Movement - The I seem to move at a slower rate than the S.  The blue seem to not move at all.

Lifetime -  The green are infinite again, the blue are infinite and the red are probably infinite except for the attrition from getting killed.

Infection Rate -  Seems to be about medium.  An I can easily infect an S but at the same time the S can easily kill the I... so its probably fairly balanced simply because of the equilibirum between these two variables.

Zombie Scenario (Apocalyse)

Zombie Apocalyse) Scenario Description

A sample simulation where the zombies successfully eradicate all life.

Thoughts on the Zombie (Apocalyse ) Scenario

Similar to the above this uses green for the Succeptable(S), red for the Infected (I) and grey for the dead or (R) state.

Movement - The movement of the red and the green seem fairly similar.  About "medium" when compared to all the other scenarios.  One of the big issues is "Jumping" where the infection seems to spontaniously jump like a spot-fire ahead of the interface between the two groups. This causes a much faster spread as its not restricted to the infection "front".

Lifetime -The green is infinite until transformed. The Red appears to be fairly infinite and the grey is permanent.  The I seem to "kill" about 25-30% of the S that they encounter, while there does not appear to be much "killing" by the S of the I.

Infection rate - This seems pretty virulent.  The infection rate is pretty high and the speed of infection is also high.  This creates the "contageon" style apocalypse.

Vampires Scenario

Vampire Scenario Description

These vampires are more selective than the zombies; They only kill what they need - and turn fewer victims into vampires. This gives us a simulation in which a large proportion of the population end up deceased, rather than converted into vampires.

Thoughts on the Vampire Scenario

Watching the scenario, its hard to see many of the rules. If this is based on the SIR model again then we only have Succeptable(S), Infected(I) and Recovered(R).  What is a recovered Vampire?   In the Gif movie of the model run it looks like the infected are red, the succeptable are green and the R are grey. There seems to be an intermediate state of yellow, which I guess is a temporary transitional state between uninfected and infectious.

Movement - S are slow.  I are fast, and R are stationary.  Yellow move at the same pace as S.
They all seem to use a similar movement(mixing) algorithm of moving in a straight line for a random amount of time before randomly turning 90 degrees.

Lifetime - The I seem to have a finite lifespan. Either this is because they are modelled to die or they turn into the grey "Recovered"? The green state seems to have an infinite lifespan.  The yellow state seems to be fairly short.. maybe about 5 time steps.

Infection Rate - This seems to be quite high as the red agents really plow through the greens once they get going with an infection/kill rate of about 1red -> 15 grey. However the reds are only reproducing very slowly.

Werewolves Scenario

Werewolf Scenario Description

Werewolves obviously only get the chance to strike for a short period of time each month - and in many cases, when infected, go about their normal life for the rest of the month. 
This gives us an interesting scenario in which the werewolves are able to spread, unhindered, throughout the population. When the phase of the moon is right, each werewolf has an ample collection of nearby individuals to attack - creating many 'pocket' locations from which the infection speads.

Thoughts on the Werewolf Scenario

In comparison, this has a slower start-up period and a higher kill rate.  Again S are Green. I are Red and the R are grey.  Again there is a transitional yellow state.

Movement - The reds move very quickly and do not change direction as frequently. Green and yellow are slow and grey are stationary.

Lifetime - The green and grey are infinite.  The reds are much more resiliant in this scenario. They seem to last almost indefinitly.  The yellow state is again quite brief.

Infection rate - This seems slower than the vampire scenario but has a very obvious tipping point.  However, there are some very long lived greens that seem to have multiple contacts with reds and remain un-infected.  So it seems that the infection rate is lower than the Vampire scenario, but is similarly effective as the agents move more quickly and have more "chances" to infect resulting in a similar infection rate over the whole population but a lower infection rate for individuals.

Final Thoughts

These scenarios seem to be fairly simple models with only a couple of variables which results in fairly simple outcome results.  It's not far from Conways game of life.  So whats the value of this system?  Hmm... nothing much comes to mind. Its a fun way to visualise simple 2 dimensional models with limited variables. That being said, I have not dug into the capacity for extension.  But then again, if I have to extend's just me making it do things that it doesn't currently do, so it could be turned into anything with enough resources.  The point is that its currently just a basic system.

You can use it to model some complex systems and play around with some numerical models, but anything more complex with hidden states, environment effects, communication layers or resource models are probably way beyond what it is intended to do.

Emergent Results - Perfect for exploring the results of  deterministic models.
Emergent Behaviour - Zero.  This sucker seems to be deterministic and uses generic agent classes.

Wednesday, November 14, 2012

SimCity... and the GlassBox Engine.

Nice.  Good agent model.  Good information views. Good analysis and no win state....all within a nice engine.

I wonder what the engine can do?  Is it moddable?  Can we use it to make all the stuff I have always wanted to make but have always had to build from the ground up.... please let it be so...

Let us learn about the Glassbox Engine

Insiders Look: Glassbox Game Engine Part 1 - Resources, Units & Maps

Insiders Look: Glassbox Game Engine Part 2 - Scenario 1 - The Ecconomic Loop

Insiders Look: Glassbox Game Engine Part 3 - Scenario 2 - Water and Pollution

Insiders Look: Glassbox Game Engine Part 4 - Scenario 3 - Fire


Interesting Article

Monday, November 12, 2012

Grading Legacy Code and Estimating Cost

The above is an interesting set of criteria for the assessment of a codebase.  I think they are valuable indicators as far as code "smells" but they do not really provide a framework for estimation of work. There are lots of signficant issues that the above article does not mention, the biggies are all around the users of the system.  Whats the documentation like, how big is the user base, what is their investment in the system?  These are all things that are outside the world of "code" but still have a huge impact on the actual "cost" of changing a system.  We, like any ecconomically minded type who might need to manage an acutal business need to build some sort of reasonable cost estimate.  So brainstorm for some decent cost drivers and name those variables, then figure out an estimate for them and get your spreadsheet out. See below for a dummy example I have concocted out of thin air...

Lets name some variables in our model:

TC  - This is Total Cost of the Change Request
U - This is the Cost of the Change to the Users (People Factors)
D - This is the Cost of the Change to the Documentation (Writing, testing, production, distribution )
P - This is the Cost of the Change to the Software (Person Hours to Implement the Change)
Pe - This is the Cost of the Change to the Software Environment (Code Storage, Test Suite, Dev Tools, Reporting Tools etc)
He - This is the Cost of the Change to the Hardware Environment ( Programmers Hardware, Testing Hardware, Deployment Hardware, User Hardware, Wires and Networks etc)

Lets assume that for any of these variables there is a fixed "unit cost". This is however a small fantasy as each will have a different cost model with fixed and variable components. Its your job as an analyst to figure out what these are in each business scenario... AND DOCUMENT THEM.

We can supply some general cost estimates for the model for entertainment purposes.

U - Informing a single user about a change to their software takes 1 email.  This means this will have a fixed cost of  time to writing the email, spell checking it, testing it with a couple of sample idiots and then figuring out who is on the distribution list, sending the email, gettting the abusive feedback from the 10% of people who cannot read, or did genuinly find a problem and responding to them with 1-10 follow up emails (average 3 emails).  So the true cost of informing a userbase via a single email will be:

U = 1(Time to write initial email, spell check, test, distribute) + ((Number of Users / 10) * 3(Time to write follow-up email))

If we assume the time to write, test and distribute the initial email at about 1h and the time to write a followup email at about 5min, then for a userbase of about 100, we get:

U = 1(60m) + 10*3(5m)
U = 3h 30m at the rate for a technical writer or trainer of $50 per hour
U = $175.00

D - Update the documentation, remove old copies of the documentation from circulation. Since writing documentation can be done with varing results, this will be a matter for consultation with your technical writer..( what do you mean you do not have a technical writer?  You get your programmers to write the users docs?  Hahahahahahahhahahahahhahahahaahhahahahah... you get the idea.  This is just insulting to assume that programmers have some magical talent at communicating, educating and illuminating people. Go and find a real technical writer who can show they have produced documentation that users enjoy using and hire them.)

Lets assume that you have the best possible scenaros of a simple centralised distibution system (website, internal server..etc) that allows you to maintain a single copy of your documentation and keep it up to date. You also have a competent technical writer who knows how to communicate with the Users, can illustrate the effect of the change in terms of concrete usage scenarios to the various users and can deal with the testing and feedback around changing the documentation.  Lets also assume that the change involves only a single location change to the documentation as there is no cascase of dependencies within the documenation that creates a change-storm. 

So assume the Documentation will involve:  Write the changes and inegrate with the existing docs, test with a sample of the user base, modify if required and then deploy the docs to the doc server.  Notify all users. Deal with any resulting follow-up emails(1-2, average 1.1) from the 2% of users who whinge about doc changes and can't understand well written documentation.

D = 1(Time to write, test, review and distribute) + ((Number of Users / 50)*   1.1(Time to write follow-up email))

If we assume that the time to write a straight forward change to the docs might be 2h, with the time to write a follow-up email as above (5m) with the same userbase as above (100) then:

D = (120m) + 2*1.1(5m)
D = 2h 11m at the rate for a Technical Writer of abotu $50 per hour.
D = $109.17

P - Now this is really the meat of the article above.  It was looking at some of the big variables and trying to give some sense of what they were in the experience of the author.  Fair enough.  The problem was that the author didn't really provide any estimates or even a possible range for what they might be.

The problem really is that we need some estimate for a fairly straight forward change, when there is no such thing.  So to keep things moving, let's keep it simple and say:

P = all the changes a single programmer can make in one hour + the cost of unrolling the changes in the event that it turns out to be a bad idea. As this happens once in every 10 changes made... thats a possibility of 0.1.
P = 1(hourly rate for a competent programmer) + 0.1(hourly rate for a competent programmer)
P = 1($50) + 0.1($50)
P = $55 

Pe - This is always going to be complicated and very dependant upon what the existing system is, the number of programmers and managers who are using the system and what the cost of transitioning to the new system may be.  (Also consider the hidden cost of transitioning back to the old system if the new one does not pan out)

Lets assume that the cost a simple scenario is something like changing a test suit, while a worst case scenario is a whole new IDE, Test Suite, Build System, Code Repository, and set of scripts and glue code to make it all work together. 

Since its reasonable to assume that any change will require tweaking a test system this should form the bulk of our constant. However, as there is virtually an endless stream of "maintenance" costs with maintaining a coding environment, we should include a small constant to represent the cost of keeping a coding environment up to date and the knowledge of the programmers up to speed.  Assume we have 5 developers who need to play nicely with this system in the shop.

Pe = (10m for a programmer to write some new tests and verify them) + (Number of Programmers) *(10m for maintenance)

Pe = ($50/60*10) + 5 * ($50/60*10)

So the best case scenario gives us:
Pe = $50

He - The implications of a system change that causes hardware changes could be pretty much anything.  At the small end is something like the additon of a peripheral to one of the developers workstations, while at the big end is a requirement to update all the machines in user-land.  The more common scenario might be something like an update to a test machine or a build server, but in general, most change requests would usually not have an impact on the hardware environment.  However, we need to put together a constant for our model, so here goes.

The most frequent scenario would be ... um.... an upgrade of some old machines in userland that have not been kept up to spec.  Say, 1 in 100 machines across the whole of userland.  But since this is only triggered every couple of years...  we can estimate it with the following (N of users still = 100, cost of machine is ~$1000 for a reasonable workstation)

He =  (Number of users/100) * (cost of new machine)  / (2*365)
He = $1.37

So now we have some numbers to play with... lets play with them:

Trigger Scenario
You are handed a code base and a request for change (bug, new feature... whatever) and a question about how long(how many man hours or whatever cost metric you use).

This could be:

Response Scenario 1. In the best case scenario, no work is needed and no time is spent because you already know that the change is not required. Ideal but not the norm...
TC = 0U + 0D + 0P + 0Pe + 0He
TC = $0

Response Scenario 2. Some investigation is required, some small code change is required, users need re-education about the change or new feature. This is kind of our minimum possible change that touches the system.
TC  = 1U + 1D + 1P + 1Pe + 1He
TC =  ($175.00) + ($109.17) + ($55) + ($50) + ($1.37)
TC = $390.54

Response Scenario 3.  Significant changes are required.  There is a mess of dependancies. There is some cruft that is in the middle that will need refactoring and the documentation is a mess.  This is probably going to spill over into some renovation on the programming environment and there are a bunch of possible hardware issues.


There are about ... well everyone in usersland will be affected. Most will see a couple of changes.
About 20 places in the documentation that look like they need tweaking.
The code looks like it will take a week with two coders on it.... 35hrs per week =
The test suit is ragged and smells like a teenagers sock... maybe 2 coders for a couple of weeks
The hardware could play out or might be cause a couple of junkers to be upgraded... maybe

TC = 200U + 20D + 140P + 140Pe + 2He
TC =  200($175.00) + 20($109.17) + 140($55) + 140($50) + 2($1.37)
TC = $51,886.14

Response Senario 4.  Insert worse case scenario here... imagine that not only have you been presented with a legacy code base, but it looks like it was written by the minify command, some of your coders are not familiar with the language, its a proprietary IDE that you do not have licenses for, it is hardware specific so you will need to re jig some or all of the test system and it may force a forklift upgrade of every machine in userland.. oh and the documentation was written by someone with hostility issues towards users...

I leave this as an exercise for the reader to calculate...

Paranoia on the Security Frontier

Just read this article on the issues the American's brains trust are having with suppliers of major network infrastructure components.  The point of view expressed and the stunning hubris... is just so... sad. Basically the article says that the US gov is paranoid about the Chinese gov being able to pop some malware on some backbone switches at some point in the future.... maybe...

Firstly, this article is yet more China bashing.  Although to be fair there is a little bit of acknowledgment that there are other players in the game but none are named or particularly have the finger pointed at...

Secondly,  the fact that American manufacturers are simply assumed to be free of any government influence is just a tad ideologically blind.  Everyone outside the US is paranoid about the US spy services and what they might be inserting into the Internet infrastructure... but that goes without comment.  LOL. 

The silliest bit of all this is the naive assumption that the US spy services are somehow automagically on the side of the average US citizen... hmmmm?? Said who? Is there any evidence to support that point of absolute belief? Hmmm... could be some evidence for both sides of that argument.

Anyway,  as a third party country who gets to buy from both suppliers... we're just a little bit paranoid about both of them. As mentioned in the article.  At the end of the day... there's nothing for it except to do some independant verification of all significant network infrastructure and design networks to be able to identify and withstand the effect of compromised equipment. 

In any case, its often not the designed in back doors that prove the biggest problem, its the exploits that appear from independ players and the side effects of poor network planning that have the biggest problems.  The other problem with backdoors is that you never know who else knows about them.  Since you can bet that the US spy guys will have purchased a couple of these routers and they do have the resources to take them apart and find any useful compromises... that any backdoor that is inplace or could be inserted via patches is able to be compromised by US players just as easily.  Also by every other 3 letter agency in the world... it would then be a fairly simple activity to block each other from using the backdoors while still being able to use them themselves... unless they wanted to let the others think that they did not know about it but still wanted to be able to block them...

I'm sure that in the minds of the politicians it's all scary to think that someone else can reach out and switch off your backbone routers or do bad things with them... but a simple firewall and some physical seperation should prevent that kind of scenario.  Getting some kind of command and control interface to a backbone router should be incredibly difficult via the actual feed line.  They should be controlled via a complely different internal network that is not carried on the public feed.  This provides both physical and logical security. 

This would prevent them being compromised by either some "foreign government types" or by criminal, hacktivists, rogue spy types or other trouble makers.  But like always, it does not prevent them being compromised by the staff of the backbone provider.  As always, people are the weakest link... not the machines. All a spy agency needs to do is compromise one employee and the whole system fails.... but then again, thats what spy agencies have been doing since year 1.

Must be nice to live in a world where all you need to be afraid of is some malware built into a backbone router.  Do you think the US and Chinese spy kids are trying to rev up yet another cold war to keep their budgets?  Most of us are actually worried about non-state players taking down the networks rather than state backed players.  They have much more interest in taping the flow of information than simply trashing the place. 

There are just so many old-school points of view that underpin this whole debate that are no longer relevant.  I have no doubt that every spy agency in the world wants to pwn every backbone switch they can.  They all want unfetted access to every data centre in the world and everyones email, game sessions, chat boards, porn habits, online bank accounts, bot nets..blah blah blah... but the point is that this is a massive fire-hose of data that is simply a monster to try to do anything comprehensive with.  Very few of them have the sort of infrastructure to store, process or make sense of this in a wholistic way, so mostly they will continue to just dip their toes in while they play paranoia games.  The second one or the other gets enough capacity to be able to control a substantial slice of all this action, the whole concept of cyberwar will be declared "won".  Cause just having the ability to "switch off" someone else's network can be implemented much more cheaply than putting some bad malware in everyone elses routers.  This is why the spy agencies still exist and are still able to out-muscle all the small outfists like the hacktivists and criminals, is because they can still mobalise a set of trained and motivated people on the ground to go and "act" upon a foreign govenments network infrastructure if they so wished. All the wanna-be organisations simply do not have the resources to reach out and touch someone in a systematic way.  Just to make it even more difficult, all the backbone providers spend every day attempting to armour and fortifiy their infrastructure against everything the hacker/criminal/vandal set can think of to stuff things up.  Think of this as crowdsourced penetration testing.  The idea that some backdoor could exist that would be exploitable by a foreign government that could withstand this kind of probing is possible... but not probable.

It reads like some sort of bad plot from a really cheesy cold-war thriller... as I ranted somewhere above... its just a bit sad.


Thursday, November 8, 2012

Finding my motivation to code again

I have been wonding about what to do to re-invigorate my love of coding.  I figure other peole have the same problem from time to time.

I have just come of the back end of a hecktic year of many small projects.  Because they are "work", there is only so much personal investment that I have in them.  I do them, and I do them well... but it's mostly repetative and ... well work.  It's not fun. Very little is novel.  There is little creativity or problem solving.

I find that after a while, this really sucks me dry as far as motivation to pick up a project when the pressure is off.

So my question to myself was, how do I find my passion again?

The first solution I tried was playing some games.  Honestly, most of the games seem very much Me-too type things that remind me of games from a decade ago.  The thought of diving in a fixing broken game play or hacking on yet another creation kit for yet another half assed clone game... blah!  These are solved problems... they are not even very fresh problems.

Brain training games are even worse... (since I kinda work on them all year anyway... ) they are utilitarian but not ... inspiring.  

The next thing I tried was some little coding competitions.  These were nice.  They got me back to my roots of solving small bounded problems quickly.  It was a challenge to do it and it forced me to use some basic coding skills that have been getting rusty through disuse.

The best problem set I have looked at so far are from Google Code Jam.  They are quick and bite sized.  The data sets are well developed and the online judge does not give you any hints.

I have found a few more online but have not yet explored them...

The last thing I have tied is doing something old in a new way... I have started working my way through all the Kahn Academy videos... refreshing, renewing, re-finding ideas and concepts that I have not had to talk about or explain for ... well, a long time.  It's nice.  Kinda familiar, kinda half remembered.  A good refresher...

Maybe there is something there for you?

Tuesday, November 6, 2012

How to populate a Content Control Combo Box with multiple items in a Word 2010 document via a Macro

I am building a data entry form using a word document.  The logic of why this is a good choice is not relevant.  My problem was that I needed to add a set of combo boxes in table cells, each loaded with a list of option for the user to pick from.

There is the option to hand enter each list item... but as I had about 100 items and a dozen duplicate combo boxes... this would have been painful.  The fact that I would need to update this list in the future just made it torture. So... is there a faster way?

After some googling without any success, I came up with a very quick and dirty method.

My over view is:

I have the list of items I want in the combo box in a text file in the same directory as the word document.  (Note that each item must be Unique as the combo boxes do not like duplicates)

I have built the word document with the Content Control Combo boxes in the correct locations and saved it to the same directory as the text file.

I then added a new module to the word doc via the VBA Editor in Word and wrote this simple little macro.

Option Explicit

Sub PopulateCareProviderComboBoxes()

    Dim itemFromFile As String
    Dim cc As ContentControl
    For Each cc In ActiveDocument.ContentControls
        If cc.Type = wdContentControlComboBox Then  'checks if the control is a combo box
            cc.DropdownListEntries.Clear 'get rid of any existing entries in the combo box
            Open "CareProviderDumpList.txt" For Input As #1  'this is my text file with the items I want to add
                Do While Not EOF(1)
                    Input #1, itemFromFile
                    cc.DropdownListEntries.Add itemFromFile 'put the item from the text file into the combo box
            Close #1
        End If
End Sub

I only needed to check if the control is a combo box, as all the combo boxes on my form are the same.  You may need to identify a specific combo box.  You can do this by testing the Title property on the Content Control object.


If cc.Title = "Customers" then .... 

Once thats done, I simply ran the macro to load the list from the text file to each of the combo boxes. Then saved the word doc with the new items in place.

Job done.

More on the Future of Universities

Saturday, November 3, 2012

Regulation as a structure for creating economic micro-climates

I have been looking at the way regulation in industry stimulates corporate behaviour. 

I find it interesting that the addition of regulation stimulates employment opportunities and "work activity" around the regulation. 

* Oversight and enforcement behaviour from "regulators"
* Avoidance and complicance behaviour from those being "regulated"

This is fine and obvious.  The interesting this to me is how every regulation creates niches that small operators can use to enter the market.  Exactly like the idea of micro-climates within an eccosystem.

Take for instance a large open grassland.  Large herds of herbivors roam as they wish and grow to huge proportions.  This is the effect of companies in an un-regulated space. They are not differentiated and are generally circular-ish in shape.  Their members are randomly distributed throughout their mass and there are no threats.

Now introduce some small number of predators. (Regulators) who start to pick at the edges of the herd.  The herd either quickly adapts or is quickly obliterated.  The herd adapts its behaviour simply by becoming more cohesive and starting to fight as a group.  The herd still moves as (roughly) a circle across an open landscape.  The preditors have no opportunity.

Now introduce some sort of obstacle within the environment.  A line of cliffs, a fence... whatever.  This is effectivly a "rule" that governs where the herd can move and what it can do.  The herd, being a self-organising system, adapts by avoiding the obstacle ( or suffers a fairly catastropic injury) 

The interesting thing is that the larger the herd, the more efficiently it moves when it stays clear of the obstacles.  So there is a little fringe of ground near the obstacles that is not grazed.  It now presents a resource opportunity for a small herd or something else to exploit.  Thus we have a micro-climate around the obstacle, that is formed by the lack of exploitation by the larger groups who cannot effectivly use their scale to exploit the small niches.

So these micro-climates become "nurseries" for nurturing the next generation, similar to mangrove swamps which shelter small fish from the large predators.

In practical terms, if you look at the American banking and financial industry, you an see the effect of the removal of regulation.  The big groups have grown without constraint.  They have absorbed everything from share trading, to financial managment, to banking, to insurance, to mortgages, small business financing etc.  There is no way small entrants into the market could compete with that size company unless they are in a sheltered area that the large company does not want to compete in.  This is exactly what has been happening.  Take a look at all the small entrants in the industry and you will find them in little "niche" areas servicing(exploiting) populations that do not have enough "margin" to be of interest to the large groups (very poor people and small small businesses.  but they have even figured out that by grouping them together and selling them as derivatives, they can use scale to exploit this niche too), or those that the large group do not want to be associated with ( used to be criminals, migrants, socially un-populare industries, but since they are no longer concerned with repuation as it cant hurt them... is virtually no one)

So, simply by removing all the obstacles, the groups in the finance industry have grown and consolidated into a number of mega-herds that roam around and decimate the landscape by over-grazing and trampling whatever remains... tada! Global financial crisis.  (I know this is a simplification...)

The other intersting thing is that the lack of regulation has expanded the space in which the herds can move.  This has occured by the "removal" of partitioning regulation between the financial "spaces".  So industries that were previously seperate, such as insurance and banking, have merged together into a seamless amalgum.

This amalgumation of the financial industries/spaces into a single "whole" has also amalgamated the effect of a "change in the weather", which previously may have effected each different eccosystem differently, now effects the whole space in the same way.  This makes for a frgile system that is prone to extreems of boom and bust... tada!  GFC again.

Looking at the European environment, there are still a lot of structural obstacles in place within the financial space.  They have a lot of debri from the geopolitical amalgamation of the Euro-zone.  This is to do with the cultural remanants, the language barriers, the different local regulation models and historical artifacts that are still shaping their individual banking and financial systems.  Its interesting to note how resiliant they have been, even thought some of the countries that were carrying large debit levels have crashed... others survived.  While the US, that is one cohesive system, took a fairly massive blow that was distributed across the whole system.  The only reason it survived was scale.  The size of the herd allowed it to survive the storm.

The Europeans are currently busy trying to pick each other up and playing a game of pass the parcle with debit generated by some historical habits.  The interesting thing about the Euro-zone is just how rich a set of micro-climates exist.  There is a massive pile of different banking and finacial systems still bouncing around in that space.  Lots of small players who can potentially grow as the big ones fail. 

This is all simply statement of fact.  It's not particularly a judgement about the success or failure of these systems.  Any large system is essentially "unique". There is no "correct" way to structure such a system.  In any given environment, there are variables that allow some individuals, groups and populations to thrive while others fail.  The only point I am making is that by understanding the effects of these structures and the environmental variables that they create... it becomes easier to predict the effect of manipulating these artifacts.

I think that the biggest problem all the political regulators have is that they think they have something different to all the other environmental manipulators, farmers, hunters, fishermen. But in reality they need to learn the lessons of the past and be very careful when cultivating and exploiting a monoculture. It can all go very wrong if that one crop fails.