Incredipede：一个神奇的游戏

http://incredipede.com/

这真的是一个神奇的游戏，代码估计是用 C# +  Farseer 物理引擎写的！

这创意绝了～

游戏是要求玩家创造一个生物，然后生物重复某种动作，不断前进。当它卡住的时候，玩家可以改造这个生物的形态，然后让它继续前进～

Best regards,

TimNew
------------

If not now then when?

if not me then who?

Release your passion
To Realize your potential

I am a pessimist, I feel I'm living in a world without light.

But I am also a prayer, I believe I’m going towards a world full of sunshine!

Posted via email from 米良的实验室

TDD vs Natural Selection : Part II

As discussed in previous part, both TDD and natural selection can produce suitable designs. But there are costs.
The design from mayual selection is just perfect, but the cost is 99% unsuitable species die out. It is the cost of life.
Same to TDD, except TDD isn't so cruel. If you try to write a piece of code in TDD and pure factoring way, which means all the designs are in order to eliminate smell. And you might find that to eliminate the smell sometime is not so easy that you can have it done in minutes. You might need several tries to find out the most proper approach, since you might find that you just introduced a new, and maybe more serious smell while you eliminating a smell. Sometimes you might find that the upcoming new smells just drive into a dead road, and you just want revert the changes and retry from a fresh start. In worst case, you might find you can hardly find the right way, and you just got lost in the code.
In some simple project, you might find the situation is just acceptable, but in some complex project, you can hardly do that or you might find at the  end of the day you and your pair produced nothing with great effort.

So in my opinion, TDD doesn't mean no design at all. When you practicing TDD, you must focus on the detailed code. At this time if you can easily got lost without the guide from a clear, more general, high level vision. It just works like the architecture design or general solution to specific type of problem.

Such design can save you tons of time wasted on times of retries.

Sent from TimNew's Desire HD

Posted via email from 米良的实验室

FluentAssertion is not compatible with xUnit.Extensions

I met a weird problem that I found the Resharper Test Runner hangs when I introduced theory test case in my unit test. 

After some spikes, I found the problem seems caused by the incompatibility between FluentAssertion(http://fluentassertions.codeplex.com/) and xUnit.Extension (http://xunit.codeplex.com/).

It is wired, and there seems to be no quick fix.

So I replace the Fluent Assertion with Should and Should.Fluent(http://should.codeplex.com/), which is a port of ShouldIt(http://code.google.com/p/shouldit/). 

After that, everything goes well except the syntax between Fluent Assertion and Should Fluent are not compatible with each other, although they're really similar.

But Should.Fluent doesn't support something.Should.Be(), it requires something.Should.Be.Equals(), which is really annoying to me.

According to the Fluent's introduction, Fluent is a direct fork of xUnit. And I'm not sure what's the impact caused by this.

Best regards,

TimNew
------------

If not now then when?

if not me then who?

Release your passion
To Realize your potential

I am a pessimist, I feel I'm living in a world without light.

But I am also a prayer, I believe I’m going towards a world full of sunshine!

Posted via email from 米良的实验室