寫!

locus (part1)

人生是甚麼? 幾乎每總比喻都有其獨到之處, 但有其獨到之處, 也意味著不足之處更大。

在這刻, 我思考到的是, 安全感和慾望的較量。安全感似乎也是一種慾望, 但這種慾望似乎增長的方向是和其他相反的。一個人行為的最終決定, 取決似乎不是渴望所推動的意志, 而是這兩種慾望的比較。推動意志的強弱, 我覺得像是一種張力, 定義是意志愈強、張力愈大, 而張力愈大, 行為愈會模式化, 像我們常說的性格鮮明。

人生的際遇, 似乎會改變張力的強度, 認為自己有能力改變人生的人(external locus of control)張力應該是較少, 和認為自己的人生已是固定的(internal), 張力應是較大。這是這個框架下其中一個應用。

至於去完善這個框架, 暫時也沒太大需要, 我所說的事, 可能會用到, 我先說明一下而已。

下一篇可能不會公開...

發表時間:2011年10月9日 | 評論 (0) | 全文

template 留低

 

 
<div style='position:fixed; right:0;bottom:0;z-index:5'>
<div id='blackcat'>
<div class='left' style='background:#333; opacity:0.8;border:1px #000;padding:10px;border-radius:5px;color:#FFF'>
<iframe src="http://player.vimeo.com/video/20922586?title=0&byline=0&portrait=0" width="251" height="141" frameborder="0"></iframe>
</div>
 
<img src='http://www.a-cyclone.com/images/ukagaka_04.png'  class='right' />
</div>
<div style='background:#333; opacity:0.8;clear:both;padding:3px;border-top-left-radius: 6px;'>
<a onclick='$("#blackcat").toggle();' style='color:#FFF;cursor:pointer'>Toggle Icon ▼</a>
</div>
</div>
發表時間:2011年10月5日 | 評論 (0) | 全文

有關白書

幽遊白書這部燴炙人口的動畫有着一個耐人尋味的名字, 在Hunterxhunter 當中作者有解釋過其中因由, 但當中有著不同的意思, 如只要單為避免和最遊記撞名, 同幽遊錄或者幽遊物語就可以了, 用不著用一個那麼嚴肅的字。我認為由記改為白書, 唯一合理的原因是打從改名一日開始, 作者就打算把這個故事的主線由小閰君派出幽助的行動作為主線了, 因此, 小閰君和是這個故事出現的主因。

發表時間:2011年10月1日 | 評論 (0) | 全文

日記 - 感情線上

今日衛視播感情線上, 已經大概是第三次看這部戲了。

劇情仍是覺得很感人, 除此之外, 這次一直聽主題曲是卻聯想到GitHub 這個網站, 歌詞的確和它很合襯呢!

一個獨自在發燒 
另外那位唇上結冰
負負得正
各取需要 多玄妙
不同的開發者有不同的才能, 各取需要而已


也許 上天不給我的
無論我兩臂怎緊扣
仍然走漏給我的
無論過去我怎失手都會擁有
這段說到Git 等SCM 的好處, 常常才沒有backup 的時候出事只會覺得是上天的手段, 但Git 可以在怎麼失手的情況下找到所有build 的副本, 太安心了

一個恨浪漫太少
另外那邊期望太多
實現不了
結果將會 多微妙
也許 上天的一對手
移動你與我的分寸 
行前或留後這對手
其實正要送我給你不要鬥
也許最不同的fork 也可以merge 吧

分叉的感情線 
正等我為你蔓延
彼此的感情線 
交錯發展 怎麼捨得去剪
高潮來了, 把master fork 了, 然後不斷的蔓延, 而不同的fork 也交錯發展, 不斷的merge 和fork, 而每個fork 都有它的價值, admin 也不能把它剪掉

心在你身邊 
就算隱形亦有一天遇見
那些感應 多靈驗
也許 被喜歡的女人
從自信散發的光線
朦朧或明豔 不太難望見
每份fork 都可以清楚看見, 你想誰陪著你都可以(?)

分叉的感情線 正等我為你蔓延
彼此的感情線 早佈滿對方雙手
你的感情線 看出我下個十年
分叉的感情線 總會有某天一起發展
也是高潮, 說得很傳神, 把感情線看做forks 走的歷史記錄就好

等適合時候孤男寡女會連線
深呼吸等適合時候一場交戰
等適合時候孤男寡女去連線
深呼吸等適合時候一場交戰
要等的就是在適合的時候merge, 成為一個更優秀的程序

 

發表時間:2011年9月18日 | 評論 (0) | 全文

有關lol

幾過那麼多個星期, 英雄也試得很清楚了...

因為懶惰的關係, 也打了很多場中級AI, 我一直有在想一個頗不切實際的問題, 如果把裝備任意配搭, 究竟那一個才是最強的DPS 而可以作為一個真真正正的carry 呢?

最初時我想是法師, 因為法師的爆發很強, 例如brand 或者veigar, 主要原因是ap 可以撐到很高, 但是法師最大的問題是不能推搭, 當你聚集了全隊最高的金錢時, 又不能把對面推下, 是得物無所用, 所以很少法師可以作為一個可靠的carry.

之後覺得Cho'gath 也很不錯, 血厚之餘也可以做ap, 但是, 他的爆發力太弱, 就算ult true damage 到1000 到後期, 也不過是對面的半血不夠。

後來想到是Teemo 或者Twitch, 他們的秒傷十分不錯, 在中期的確是起到不少作用, 但是如果對面的甲厚了的話, o他們這樣的距離做成的傷害其實不化算.

後來還原基本步, 感覺master yi 和tryndamere 才是最強的。它們的傷害的確很可怕, 但是其中不善之處就是他們的ult. master yi 的ult 是加攻速和移速, 因為最大攻速是cap 了在2.5 正常情況下, 在裝備phamtom dance 和trinity force 的時候, yi 已是過2, ult 是浪費了, 加上, 血少是最大問題.

tryn 的ult 是不死, 算是遊戲中最scalable 的招數了。但是這也引致tryn 其他三招攻力奇差... 只能依賴所有的裝備了。但是血也是不夠, 如在偷塔期間遇到敵人, 旋風斬一記放下之後也是還在塔邊, 對於全攻carry 來說其實有點危險的。但是我覺得tryn 還是其中一個最好的carry. 

而我認為最強的carry 是tristana, tristana 比起其他角色的實用之處莫過於是她的天斌十分的scalable。其他的英雄都有一個通病, 要麼功能可以用裝備補足, 要麼到後期作用不大。只有tristana 她改變了裝備不能改變的東西: 射程, 令她由一個近炮兵變為一個全遊戲最遠射程的英雄...

而她的Q 技也令配裝到遠一個極點有平衡。lol 中, 大部分的數值在累加後都有減少功效的, 所以要有強攻就要在可能提高攻擊的東方下手:  要知道Magic resist 也好, Armor 也好, 大多數到後期看到70%以上, 人們就會停手了,而addps 比起apdps 最大的好處是不用盲目撐AP,AP 成長下去難之餘技能通常只吃0.7而對手又只吃0.3, 實際上到後期不算很有爆發力, 而法師又失去普攻手段, 有點不行。

addps 成長幾乎已有共識: phantom dancer x1 和infinity blade x1 是核心裝了, 要高攻可以選barserker Grave, 還有三格, 攻速和攻擊和爆擊都加了上去, 加一層的話效果已是減10% 但我們還有三格, last whisper 也是公認了, 在物穿方面下功夫。

ad 的所以地方都加完之後也不能免去有第二層, 也不應有第三層了, 所以果斷有一把trinity force, 它可能令到幾乎所有層面都可以做到第一次提升, 

還有一件是防裝, 因應對手可以選取。

完成後, 在放Q 技的情況下, tristana 的攻速是2.44, 十分美妙的平衡。在last whisper 之下, 對著任何對手都有一戰之力了。

發表時間:2011年9月13日 | 評論 (0) | 全文

日記

I want to start to write diary once again.

morning: some surfing before leaving

noon: I went to arcade during lunch time for DDR

night: no home dinner again but hotpot in a restaurant

night2: played LOL and with a 20/4/13 cho'gath and turn out a lose, teammates and I are not pushy so they are safe for the whole game.

plan: found a bms player source code in both java and c++ and I am going to dive into one of them soon

發表時間:2011年9月8日 | 評論 (0) | 全文

抽象滲漏法則

我是在一個月前看到這篇文章的, 在這個期間, 時不時也會回想起這篇文。

在google 上似乎找不到有人轉載過, 就在這先留種吧!

感想, 本來我是想看看抽象化令事情得到自動化實現的支持理據, 可是卻找到一篇持相反意見的文章, 而家十分有說服力。令我一直的想法幾乎有九十度轉變。

在這特意推薦, 抽象滲漏這四個字實在起得太好了, 不過最可惜的是這種解釋世界演化的觀點也是要被迫於使用電腦概念來解說。

抽象滲漏法則

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Monday, November 11, 2002
屬於Joel on Software, http://www.joelonsoftware.com

你每天不可或缺的Internet裡有個關鍵的小魔法,這個魔法就在TCP通訊協定這個internet的基礎協定裡。

TCP是一種可靠的資料傳輸方法。我說可靠是指如果用TCP在網路上傳一個訊息,訊息一定會到,絕不會亂掉或壞掉。

TCP的用途很多,比如抓取網頁資料或傳電子郵件都是。由於TCP這麼可靠,連那些挪用錢的東非人電郵(譯註:指有陣子常見到的騙人信)都能完整無缺的到達,真是好笑。

相對的有另一種叫IP的不可靠資料傳輸方法。IP不保證資料會傳到,就算到了資料也可能會亂掉。如果你用IP傳送一堆訊 息,很可能只有一半的訊息到達,而且其中還有一些到達的順序和原先傳送時的順序不同,另外可能有幾個訊息的內容會變掉,可能變成可愛的猩猩寶貝照片,更可 能變成一堆看不懂的垃圾,看起來就像臺灣垃圾信的標題一樣。

這裡就是魔法所在:TCP是架在IP上面的。換句話說,TCP不得不靠一個不可靠的工具想辦法可靠地傳送資料。

為了說明這的確是個魔法,想想下面這個本質上相同(雖然有點滑稽),來自真實世界的情節。

想像你有個方法把演員由百老匯送到好萊塢,基本上就是讓人坐上車後開車橫越國家送過去。有些車會出車禍讓可憐的演員掛掉。有時候演員在路上 喝醉了就去剃光頭或刺納粹刺青,結果變得太醜而不能在好萊塢工作。另外由於走的路線不同,演員到達的順序常會跟出發的順序不一樣。現在想像有個叫好萊塢快 遞的新服務,可以把演員送到好萊塢,並且保證演員一定會(a)到達,並保證(b)順序不變而且(c)狀態完美地到達。神奇之處在於好萊塢快遞除了原本的車 子以外,並沒有新的運送方法。好萊塢快遞的作法是在每個演員抵達時檢查演員的狀況,如果狀況不佳就打電話請公司把該演員的雙胞胎送來。如果演員到達的順序 不對,好萊塢快遞會照正確順序重新排好。如果51區有架大幽浮在內華達的高速公路上墜毀阻斷了交通,預定走這條路線的演員就會改走亞歷桑那州,好萊塢快遞 甚至不會把事情告訴加州的導演。導演只會覺得演員來得比平常慢,他們甚至不會聽到幽浮失事的消息。

TCP的魔法大致上就是這樣。這種作法常被電腦科學家稱為抽象:把複雜許多的東西隱藏起來的一種簡化動作。結果很多電腦 程式的設計都是在建立抽象機制。字串程式庫是什麼?它是一種偽裝,假裝電腦能像處理數字一樣輕易的處理字串。檔案系統又是什麼?也是一種偽裝,假裝硬碟並 不是一堆不停旋轉,可以儲存位元的磁性碟片,而是一個有著層層目錄的階層式系統,可以存放一個個由一或多個位元組字串構成的檔案。

把話題拉回TCP。稍早為了讓事情單純一點,我撒了一個小謊,而且現在有些人可能會因為這個謊氣得頭上冒煙。我說過TCP保證你的訊息會到達,其實並不會。如果你養的蛇把連接電腦的網路線咬斷了,就沒有任何IP封包可以通過,這時候TCP當然也不可能讓你的訊息抵達。如果你惹毛了公司的系統管理員,他們為了報復就把你接到已經超過負荷的集線器,因此只有部份的IP封包能通過,這時候TCP是會動,不過一切都會變得很慢。

這就是我稱之為抽象機制有漏洞的狀況。TCP試圖提供一個完整的抽象機制,想隱藏底下不可靠的網路,不過有時候網路會滲漏越過抽象機制,這時就會覺得抽象其實並不太能真的提供保護。這只是我所謂「抽象滲漏法則」的一個例子而已:

所有重大的抽象機制在某種程式上都是有漏洞的。

抽象會失效。有時候輕微有時候很嚴重,反正就是有漏洞。事情會因而出錯,而且當你有抽象機制時到處都可能會發生。下面有一些例子。

    1. 像掃描一個大的二維陣列這麼簡單的動作,是由水平方向或垂直方向掃描都會嚴重影響效率,影響的大小依「木紋」(譯註:二維陣列排列的方 式)的方向而定,某個方向可能比另一個方向多產生許多的分頁失敗,而分頁失敗是很慢的。雖然寫組合語言的程式師應該可以假設自己擁有可連續定址的記憶體空 間,不過虛擬記憶體表示這種假設只是種抽象機制而已。當出現分頁失敗時或是某些記憶體讀取時漏洞就會出現,處理時間會比其他記憶體慢幾毫微秒。
    2. SQL語言希望把資料庫查詢的程序抽象化,讓你只要定義想要的東西,查詢動作的細節就交由資料庫去處理。不過在某些狀況下,有些SQL 查詢比邏輯上相等的查詢慢上幾千倍。這有個很有名的例子,在某個SQL伺服器用"where a=b and b=c and a=c"來查詢,會比用"where a=b and b=c"快上許多,可是查詢的結果其實是一樣的。照道理只要指定規格,並不需要在意程序。可是有時候抽象機制會失效並導致很差的效率,於是你就得跳出來用 查詢規劃分析器找出問題,然後想辦法加快查詢。.
    3. NFS或SMB之類的網路程式庫,能讓你「像」處理本機檔案一樣地處理遠端機器的檔案。有時候連線速度會變得很慢或是斷線,這時遠端檔案就不再像是在本機上了,而身為程式師的你必須加程式碼來處理這種狀況。「遠端檔案和本地檔案一樣」的抽象機制出現漏洞了。 這裡有個Unix系統管理員的具體例子。如果你把使用者的home目錄放在用NFS掛入的磁碟上(一種抽象機制),而使用者建了一個.forward檔案 把他們的電郵全部轉寄到其他地方(另一種抽象機制),如果新郵件進來時NFS伺服器停掉了,由於找不到.forward檔訊息並不會被轉寄出去。這個抽象 機制的漏洞就真的會把一些訊息丟掉。
    4. C++字串類別應該能讓你假裝字串是個第一級(first-class)資料。它們嘗試把「字串很難處理」這個事實抽象掉,讓它使用上像整數一樣容易。幾乎所有C++字串類別都會多載+運算子,才能把字串連接寫成s + "bar"。不過你知道嗎?不過怎麼努力,世上還是沒有C++字串類別能讓你寫成"foo" + "bar",因為C++裡的字串常數一定是char*,絕對不會變成字串。這個抽象機制呈現一個程式語言本身不給補的漏洞。(有趣的是,C++隨時間演進的歷史,可以描述成嘗試用修補字串抽象機制漏洞的過程。他們為什麼不直接在語言本身加個原生的字串類別?這實在讓我搞不懂。)
    5. 再來就是下雨天時開車沒辦法開得和平常一樣快,雖然車上有擋風玻璃雨刷有頭燈有車頂還有暖氣,這些裝備應該是讓你可以忽略下雨這個事實 (他們把天氣抽象化了),不過看吧,你還是得擔心天雨路滑,有時候雨甚至會大到你看不遠,所以在只好慢慢地開,因為基於抽象滲漏法則,天氣永遠不能完全被 抽象化。

抽象滲漏法則會造成問題的原因之一,是因為它說明了抽象機制並不真能照原構想簡化我們的生活。當我想訓練某人成為C++程式師時,最好能完全不教char*和指標運算,直接去學STL字串。問題是總有一天他們會寫出"foo" + "bar"這 樣的程式然後看到怪事出現,於是我就得停下來教他們有關char*的事情。他們也可能會試著呼叫某個需要OUT LPTSTR參數的Windows API函數,於是又得把char*、指標、Unicode、wchar_t以及TCHAR含入檔搞懂,才會知道如何呼叫。而這些全都是漏洞。

在教COM程式設計時,最好只要教學生如何使用Visual Studio的精靈和各個程式產生功能。不過萬一出了任何問題,他們根本不會知道怎麼回事,也不知道如何除錯或回復。我還是得教他們IUnknown和CLSID還有ProgIDS以及。哦,饒了我吧!

在教ASP.NET程式設計時,最好只要教學生可以在元件上雙擊,然後就能撰寫使用者點擊該元件時在伺服器執行的程式。不過處理超連結(<a>) 點擊事件的HTML程式,和某個按鈕被按時的處理程式是不一樣的,而ASP.NET實際上是把這之間的差異抽象化了。問題來了,ASP.NET的設計者必 須把HTML無法由超連結傳送表格的事實隱藏起來。他們的做法是在超連結的onclick產理加上幾行JavaScript程式。不過這種抽象機制也有漏 洞,如果使用者關閉JavaScript功能,ASP.NET的應用程式就不能正常的運作了,萬一程式師又不瞭解ASP.NET抽象掉什麼東西,根本不可 能知道出了什麼問題。

抽象滲漏法則表示,當某人發明一套神奇的新程式產生工具,可以大幅提升效率等等,就會聽到很多人說:「應該先學會如何手動進行,然後才用這 個神奇的工具來節省時間。」 程式產生工具假裝抽象掉某些東西,和其他所有抽象機制一樣都有漏洞,而唯一能適當處理漏洞的方法,就是弄懂該抽象原理以及所隱藏的東西。所以抽象機制雖然 替我們節省了工作的時間,不過學習的時間是省不掉的。

而這一切都似非而是地表示,即使我們擁有愈來愈高階的程式設計工具,抽象化也做得愈來愈好,要成為一個純熟的程式師卻是愈來愈難了。

我第一次去微軟實習時,寫了一個在麥金塔執行的字串程式庫。那是一個很典型的任務:寫一個自己的strcat函數傳回指向新字串結尾的指標。只要寫幾行C就夠了。我做的每件事都寫在K&R裡面(一本講C程式語言的薄書)。

今天為了要做CityDesk,我必須會Visual Basic、COM、ATL、C++、InnoSetup、Internet Explorer內部機制、正規表示式、DOM、HTML、CSS以及XML。一大堆比古老的K&R更高階的工具,可是我還是得會K&R 講的東西,否則我就完了。

我們十年前可能想像過,現在會有某些全新的程式設計典範讓程式設計更容易。事實上這些年間所建立的抽象機制,的確讓我們 能處理更高複雜度的軟體開發(如GUI程式設計和網路程式設計),這是十或十五年前無法處理的。這些偉大的工具(比如OO型式的程式語言)雖然能讓我們用 飛快的速度完成許多工作,不過總會有一天我們得去追查因抽象滲漏而產生的問題,到時候就得查上兩星期了。另外雖然你得雇一個以寫VB程式為主的程式師,不 過單純的VB程式師是不夠的,因為當VB的抽象機制滲漏時他們就完全卡住了。

抽象滲漏法則正在拖垮我們。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.

發表時間:2011年9月2日 | 評論 (0) | 全文

天下間最可怕的

 天下間最可怕的是自己的反面,當本性愈強,要面對自己那另一面時,也愈可怕。

發表時間:2011年9月2日 | 評論 (0) | 全文

KIMONO♥PRINCESS

I've been invited to a summer festival
Music surrounds me on this special night
I find myself getting lost in the moment
'Cause she's there dancing and you're in my sight

You're stepping along
Can't get my eyes off of you
Then I see you're looking back . at me
Could this be what I think it is?
Can feel my heart beat like a new butterfly

I know you've got to be the one
I could tell when our eyes met each other
I can't sit down my knees are feelin' weak
As I feel myself at last

You've got the cutest little smile
We can tell there's attraction going on now
Shows you're all that I need
One by one
For our love
You are my prince charming
And you make me feel like I am a KIMONO♥PRINCESS

I'm not dreaming
I know you've got to be the one
I could tell when our eyes met each other
I can't sit down my knees are feelin' weak
And I feel myself at last

You've got the cutest little smile
We can tell there's attraction going on now
Shows you're all that I need
One by one
For our love
You are my prince charming
And you make me feel like I am a KIMONO♥PRINCESS

發表時間:2011年8月25日 | 評論 (0) | 全文

音樂日誌

發表時間:2011年8月24日 | 評論 (1) | 全文