Just watched a demo of Google Glass, which provides a close view of the experience of using Google Glass in daily life.
Check out the video here:
http://youtu.be/V6Tsrg_EQMw

After watching the video, I found glass behaves a little bit different to my previously understanding, it is could be a disadvantage of Google Glass, and will hurt the experience a lot!

Current design of the display on the Glass is to project the digital image on your right eye from a very close distance, which works like you have a transparent display near you right eye.
Since the display it so close to you eye, so the digital image will fall out of focus when you are looking around. When you really want to read something from the Glass, you need to ask your eye to focus on the image, on that time, the world around falls out of your focus!

According to the video, what Google is purchasing is a technology that can interact with user without any distraction, reads, bring the user out of the world. In this point of view, Google Glass is huge improvement comparing to classic digital devices, but is still not perfect!

From the distraction view, this little disadvantage isn’t really hurt the experience of Google Glass, if you feel happy that moving your eyeball on the top right of your view very often. But form enhanced reality point of view, it is a breaking blocker!

The most basic requirement of Enhanced Reality is to overlap the digital image contains descriptive information on the optical view of real world. But for Google Glass, it doesn’t provide a way for people to see the digital view and real world, but it is not simultaneously! Because you cannot see the digital view and surrounding world clearly simultaneously, then it is impossible for Google Glass to overlap the digital image over the optical image.

That’s what I means that Google Glass isn’t really an Enhanced Reality Device as a lot of people imagined and expected!

Here are 2 images that explain the idea:

View when you look around
The view around is clear, but the map is blur

View when you read Glass
The map become clear, but the view around is blur

To solve this problem, it requires device to detect the focus point of human eye, then adjust the image accordingly in real time. But still now, we don’t have mature technology that can detect the eye focus point and compact enough to built into a wearable device.

But any way, I still believe that Google Glass is an exciting milestone of purchasing real Enhanced Reality technology in human history! It must evolve and incubate a lot of future technologies!

I have spent almost a week to fight against the code highlight system in jekyll, but finally failed.

At very beginning, I tried the “legendary” “github flavored markdown”, which supports use “```” to quote and highlight code. But soon, I failed.

Then I tried pygements, but sooner I found the perfectly local rendered code fails to be rendered on github pages, the reason seems caused because the github use a older version of the pygements.

Since I cannot fully control pygements as I expected, so I turned to a javascript version code highlighter, SyntaxHighliter.

Soon, I found SyntaxHighlighter cannot cooperate with jekyll’s markdown compiler well, so I tried several approaches to make them work together. I change part of the SyntaxHighlighter’s implementation and added several new includes liquid template based on Jekyll Bootstrap.
But it still cannot work perfect.

The problem is that jekyll markdown parser cannot distinguish the html snippet perfect, it usually try to parse the code as html.
Then I tried to quote my code with CData tag, but I found the generated html are not consistent. Some of which the “<” and “>” are escaped with “&gt;” and “&lt;”. And some other are not escaped but quoted with “”. It is really hard to deal with so many cases in javascript.

So I gave up. I gave up to use the github to render my pages. So I guess Octopress must be a good option for me.
Since Octopress is based on jekyll but with a lot of new goodies. These new liquid markups are powerful and can fulfill my requirements.

As discussed in previous part, both TDD and natural selection can produce suitable designs. But there are costs.
The design from natural 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.

After practiced TDD for almost a month, I guess I began to understand why TDD can possibly generate the best suitable design, although there is no one actually did the design work. It is interesting that if something is not intended to be done but actually has been done finally. It means that the design is actually done gradually and silently during the TDD process.
I always wondering what actually happened leads to such a result. Then I guess I have found the answer from Darwin’s theory. Think about the various lives on the planet, there is no one who designed them, but they are just so reasonable and harmony with the environment.
Why? Natural selection!
Natural selection ensures a trend of the life evolution, which makes the life to be more and more suitable to the environment, by serious survival tests. Unsuitable life just died out, the remained are the suitable.
Comparing to natural selection, you can find the similar gene in TDD. They both got tests and the test result eliminates the unsuitable design, which actually drives the design more and more fit to the requirements in a most efficient way.

Cocoa Programming for Mac OS X 里看到这么一段话～挺有意思的～～～

Once upon a time, there was a company called Taligent, which was created by IBM and Apple to develop a set of tools and libraries like Cocoa. About the time Taligent reached the peak of its mindshare, I met one of its engineers at a trade show. I asked him to create a simple application for me: A window would appear with a button, and when the button was clicked, the words “Hello, World!” would appear in a text field. The engineer created a project and started subclassing madly: subclassing the window and the button and the event handler. Then he started generating code: dozens of lines to get the button and the text field onto the window. After 45 minutes, I had to leave. The app still did not work. That day, I knew that the company was doomed. A couple of years later, Taligent quietly closed its doors forever.

可以想象，这个故事一定发生在 OO 刚刚起步的年代～那个年代几乎把 inheritance 当作所有问题的 Killer Pill～随着技术的演化，在无数的 Developer 对着一堆堆让人眼花缭乱的继承树（特别是像 C++ 这样具有多继承能力的预言的继承树）浪费的无数的 Working Hour，杀死了无数自己的脑细胞后，人们终于开始意识到或许应该有一种比 Inheritance 更好的方式去处理某些问题～ 于是有了 Composition 有了 Delegate～～～甚至把继承深度作为了代码可维护性的一个重要指标！

看新的预言中～C# 和 Java 拿掉了多继承～ 在产生变种对象的时候，Java 是采用 Handler 的新类，其实就是 Delegate 的方式～ C# 对于比较重量级的对象（比如 Form，Window，Page）依然采用 Inheritance ，但是对于轻量级的对象（Button，TextBox，MIenutem）时则采用更为灵活的方法级别的 Delegate～
C# 的方式和 Cocoa 比较类似。
Cocoa 中，由于界面采用溜达 MVC 模式～需要大量定制的对象，比如 Window，View，会采用继承重载的方式。需要改变行为时一般会 Controller，而要改变 Visual 时，通常会重载 Visual Element 对象本身～ 而轻量级的定制，或者仅仅是响应某些交互的话，则会采用 Delegate 的方式～比如 Application 的 Delegate～～

Vision 只有一个，但是 Implementation 会有很多～而对比不同语言对同一个问题的处理方式是一件非常有意思的事情～在这种对比中～才能发现不同的设计模式和实现模式的优劣～～～和在现实中的实用效果～～～～