daily murmur

Dec
31

Learning Curves of Text Editors for Programmers

learning curves of text editors

Very interesting comparison diagram of some text editors in viewpoint of programming geek, especially to Visual Studio and Emacs. I doubt how many people still use pico, those people using pine as their email client? According to what I googled from, this diagram should be released earlier 2004 and Eclipse 3.0 was just released around 2004.

We should put Eclipse into comparison and it would be more interesting to see the result. BTW, thanks for ypcat's providing this cool diagram to entertain us for a couple of minutes.

Dec
27

閒聊太極研發團隊用到的四個網路服務

Todos

來隨意聊聊,待在太極影音的研發工程師們,用了些什麼服務。隨手撿了四個太極研發部有在使用的 web services 拿來說說,隨意聊聊…

根據 programming 有名的草根人物約耳(Joel Spolsky)的一篇文章裏頭提到的,如果你要測試一個軟體團隊,可以使用他提出的 The Joel Test,裏頭簡要地列出了 12 個是非題,受測者只需要回答 Yes / No 就可以得出當論來。

Dec
25

New Theme: Color Paper

 Color Paper

Dec
18

Photos of SIGGRAPH Asia 2009 by yoggy0

If you couldn't participate the historical biggest Computer Graphics conference in Asia up now, Siggraph Asia, and you are tired of grabbing just hyperlinks about this big event, how about just photoing this event?

Dec
14

真實,有時也是很假的

 在 Pete Shirley 的 blog 上頭看到一張有趣的圖

你覺得這張圖的打燈有幾分?

Dec
13

My Tokyo Trip Photos by Ogawa

Tokyo is such a great city that I must go there again. I hope I can take a spa or Sauna next time~

Dec
13

3D Compositing in Nuke

3D compositing in Nuke

We all know that should be a trend for compositing softwares to switch to real 3D compositing. That is, you do composite by not only images/channels/layers but also the (rendered) results of 3D scenes (models, materials, animation, lights and cameras). It is so trivial to forecast this trend and all we are hesitating is the cost of migrations from our current working pipeline. And most difficult part of the migration is human being itself...

Dec
5

動畫公司裏頭 TD/RD 的抱怨

最近一直在閱讀,吸收來不及吸收的各種知識,重新審視過去我視為理所當然的觀念,哪裏需要修正,哪裏需要以不同的角度重新解釋一番,其中之一,是 animatin studios 裏頭 RD/TD,或再泛稱一點,所謂的技術人員,他們應該怎麼自處,應該在工作心理與技術能力上學習些什麼。

Coding for love 這個 blog 的主人翁,是一位在動畫產業工作的工程師,裏頭的 Stupid Things That Should Be Fixed 很好笑,雖然只有短短的三篇:

Securing Failure in Tools Development 這一篇來說:

如果,你是一位在動畫公司工作,有負責(間接或直接)開發一些工具的 TD/RD 的話,你常常會遇到你的使用者,也就是非程式設計師們,對你說:「怎麼這個程式這麼難用呀;他好像一下子就當了也;可以幫我看一下,你的程式好像不聽話唷;能不能加個什麼功能呢…」相信我,這些話你應該常常聽到的。

程式設計師的最終目標之一,是寫出一種非常酷的程式,可以把一些工作,幾乎全部給自動化,不需要任何人的界介入,就是「自動化的極致」。打開我們寫過的清單:preview render, final render, attach prman shader, create spot light through camera, auto rigging setup, auto convert textures between low res & high res, auto fix texture uv seamness, auto make animation curve's end infinity, ... what else? you name it.

然後呢,我們也常常失敗在這個「自動」上頭。使用者假設你的程式真的很「自動化,百無一失」,你也慢慢被要求成要寫出這樣的程式,但時間的壓力,加上不完善的程式開發環境,導致你永遠寫不出這樣的程式來;另一方面,比女人還要善變數百倍的動畫製作流程朝令夕改(這是種非常誇大,但很容易貼切人心的說法),讓你的程式永遠趕不上變化萬千的流程。於是呢,使用者繼續遇上問題,繼續質問你的工具的可信度,然後你繼續覺得很悶,覺得有修不完的程式,不健全的程式…

原作者舉個有趣的例子:

如果你在非常好的動畫公司,那動畫人員會坐下來,認真地看待開發工具這件事,並且有打算長時間和你一路一起研究,找出一種在各方條件下,最折衷的工具樣貌出來,並且與你做某種程度上,盡量完整的測試與試驗,然後再把它的限制與優點記下來,最後教給他的其它組員們。如果你在一家非常爛的公司,那動畫人員不覺得開發工具與他們有啥關係,所以工程師你自行開發,最後再自行推銷。如果你在一般的公司,那可能動畫人員會幫你做點測試,然後偶爾和你聊一聊,接下來還都是你的工作。

最遭的情況,應該是「一般的公司」,因為前兩者很乾脆,工具開發起來反而單純。很棒的公司下,會慢慢磨出很棒的工具來;而很爛的工作環境,那就是程式寫出來,美術人員只有聽話使用的份,也沒什麼好挑三撿四的。最有趣的是第三種情況,不上不下,於是雙方有不一致的預期,然後災難就來了。

我看到這,忍不住想到處找人聊聊這件事,實在太有趣,也太貼切了。

回過頭來,我可能無法一直持續擔任只鑽研技術的技術人了,只好把這份榮耀與成就感委託其它更優秀的技術人員,然後呢,我要去好好想想怎麼做好「技術的形而上」的問題去了~