Frustrations: Testing networked code

I hate testing network related code. Mostly because there is far too many moving parts in it.
For example you can't really unittest the actual socket itself. Because what happens if something wonky happens with the network stack? Or a process dies suddenly. How do you handle that? You can't really.

Update: last few weeks

I don't really normally do update blog posts, but I feel that it is a good idea this time.
So during last week I had the flu. A pretty nasty one at that. While that stopped me pretty much programming during it, it did allow me to gain a new perspective on things.

D has actors now!

Okay so recently it came up in the D newsgroup about akka. Akka is a pretty cool framework (Java/Scala) for multi cpu/host/thread processing of information. It also has a high degree of trust around 'its going to fail so lets handle it'.

Professionalism in open source projects

Recently in the last few days news has come to the light about how an OpenCart developer handled reporting of an issue. Heres a link for a list of everything that was said.
At the time of this writing neither Github or Mozilla have made a public statement.
However it does appear that Github has updated their community contributing guide.

CTFE where can it go?

Over the past five months I've been working quite a lot on Compile Time Function Execution (CTFE) and what I keep seeing is at the current point in time, a lot of crazy stuff can be done. But netherless very very neat.

Compile Time Function Execution, a pattern to go by

I've been working quite heavily with Compile Time Function Execution (CTFE) and D's meta programming (templates). Each of these being quite innovative. But paired together they are quite useful.
From generation of code, to handling of UDA's.

Does _your_ data model create your javascript?

So still early days, but currently I'm working on creating javascript from D data models.
Why would anyone want to do this exactly? And how did I come to this?