http://www.chromeexperiments.com/ - These experiments were created by designers and programmers from around the world using the latest open standards, including HTML5, Canvas, SVG, and more. Their work is making the web faster, more fun, and more open – the same spirit in which we built Google Chrome.I think .... I have a long way to catch the latest again -o-........
Monday, April 27, 2009
Sunday, April 26, 2009
So... the last experimental result can only be refer to the year before last year ....
see http://mrkschan.blogspot.com/2007/04/project-lab.html for the result.
This year .... I'm a citizen in the project lab ... so ... let me report the result of this year...
Today = The Day after FYP is Over...
Head count() <= 5.
Result is as expected. Looking forwards to next year's result.
Saturday, April 18, 2009
utube with HD XD http://www.youtube.com/watch?v=jjRHyPCBV3o
Monday, April 13, 2009
那麼... 科學呢? 科學又有沒有藝術的存在? 而電腦科學... 又有沒有繼承科學本身應有的藝術? 既然, 音樂是藝術的一類, 就拿音樂作一個比喻.
source from wiki...
同一段音律, 同一篇樂譜, 經過不同的人, 不同的演譯手法, 帶給人不同的感覺,不同的影響. 這.. 就是藝術嗎?
如果你認同的話... 科學, 理應亦是一門藝術!
從立論層面角度看. 由觀察, 到假設. 由假設, 到實驗與推論. 由實驗與推論, 到定論. 由定論, 到再假設.
從應用層面角度看. 同樣由觀察, 到設計. 由設計, 到實踐理論. 由實踐理論, 到測試. 由測試, 到廣泛應用. 由廣泛應用, 到再觀察.
綜合兩方面的過程, 同樣可以是... 經過不同的人, 不同的手法, 帶給人不同的結果,不同的影響. 最終亦是可以帶給人不同的感覺,不同的影響. 科學, 理應亦是一門藝術!
這一篇文章的重點, 並不在於尋找科學的藝術價值... 而是尋找科學的藝術價值在於我本身的價值.
其實... 這價值只不過是一條問題的答案... 而這條問題, 我亦層經在之前不時提出. "我在大學究竟做什麼?"
理論上, 在大學所能學會的理論與實踐手法, 在其他大學, 什至乎書本上亦可學會. 更什的是, 有很多知識在大學學不會! 那在大學的存在意義到底是什麼?
可能有人會說... 入大學與自學的分別在於, 大學有人指導. 但到了廿十世紀後, 亙聯網的出現已經令這一個說法失去其意義. 自學亦可從網上發問, 不知為什麼的, 網上亦會有人回應. 那麼.. 入大學做乜!?
很溥淺的說... 拿一張畢業証書, 出來社會找工作嗎? 沒錯! 人是溥淺而扮高尚的動物. 我亦是溥淺的人! 但是, "我在大學究就做什麼?" 這問題的答案... 我仍在尋找. 很可能, 快將畢業的同學們早已有他們的答案... 而我... 卻還沒有我自己的答案. 又可能... "我在大學究竟做什麼?"的答案就是尋找"我在大學究竟做什麼?"
這個答案, 希望有幸在研讀生涯找到. 或者... 答案就是要享受科學的藝術.
Monday, April 06, 2009
自此, 小弟不斷的留意與 GSOC 有關的消息. 直至一年前, GSOC 2008 的舉辦... 小弟心動了... 只可惜... 因為要到某銀行實習, 給了自己一個藉口, 繼而卻步於門前. 那一年... 小弟雖未能參與其中... 但亦在歐遊的期間, 參與了 Google Code Jam (GCJ). 由於未有準備 + 人在歐遊 , 結果很自然連第一round 都過不了.
這一年, GSOC 2009 舉辦了, 起初未有心動. 後來, 得到一位朋友的問題: "有沒有興趣參加這一年的 GSOC ?" 小弟對 GSOC 的情意結又一次的被觸動了.
事實上... 小弟這一年是 undergrad 的最後一年... 假如讀不上 mphil, 就是最後一年的學生生涯. 換句話說, 很大可能是最後一個參與 GSOC 的機會. 坦白說, 就算有多忙, 也要花時間參與.. 無論成功與否... 就像馬雲所說: "放弃才是最大的失败". (那麼... 不成功便成仁麼!? XD)
April 20 19:00 UTC 便是結果公報的時間, 靜候 ...
Anyway ... i will go for GCJ this year ~~~
Thursday, April 02, 2009
Proposal: Online editor for the PHP Manual ... http://wiki.php.net/gsoc/2009#online_editor_for_the_php_manual
The editor is still under development and the source can be found by http://cvs.php.net/viewvc.cgi/doc-editor/
Short Description: In order to ease the work of PHP Documentation Group, work on Online Editor for PHP Manual has already started by Yannick... The Online Editor mimicks an offline PHP documentation environment by using ExtJS as ide alike ui and providing xml-editor with CodeMirror syntax highlighting. The documentation group can make changes online, DocBook syntax check, CVS Log/Diff/Commit, patch review list, etc.
PhD OE allows PHP Documentation Group to carry documentation right ahead through the browser instead of using cvs to synchronize their local copy. There is ide alike ui on PhD OE so that the doc-group can directly edit the PHP DocBook xml online. Despite, PhD OE also eases the collaboration in an open documentation environment. Doc-group can share the workloads easily since they no longer need to pass the local modified copies around but on PhD OE. In addition to this, PhD OE does allow community contributor to submit patch so that the doc-group can review the patch in a centralized location like an issue list.
To find out the implemented features of PhD OE, visit following posts on mailing list:
Currently, there are some opening issues on the TODO list (found by - http://cvs.php.net/viewvc.cgi/doc-editor/TODO?revision=1.5&view=markup). One of the major task is to "Split main.js into several objects & files" because of the coding readability, continunity, and scaliability. main.js contains ui of PhD OE. There are 6922 lines of code in revision 1.21. It is obvious that maintaining such a large piece of codes is tidous and not that good. Thus, this proposal describe how to split the main.js and merge the js for deployment.
Right before talking about the split, let's see how to merge. ExtJS ant script make use of YUI compressor. So, there's no doublt that YUI compressor is a good choice to merge js in this project as the ui depends on ExtJS. Anyway, moving back to the split, main.js can be split based on module. I suggest Java alike model using 1 module 1 class 1 js. This is the practice I used in my own ExtJS project. Nevertheless the split is time consuming, the effort spent on this kind of refactoring allows me to better understand how the ui works and improve the structure. The proposed approach follows.
- Fork a branch to work on refactoring. The trunk keeps on development
- Refactor and Test the branch... Testing is important here! No failure should be induced by refactoring.
- Merge the modified trunk to the refactored branch.
- Freeze trunk, test the merge.
Another task is to "Clean up class.php". Again, a refactoring task. class.php is the "bootstrap" residing on the apache server ... with 4075 lines of code in revision 1.21. As written in the TODO list, initial ideas for refactoring already exist. It would be splited into several smaller classes that are quite relatively independent to each other. The proposed appraoch would be somehow the same as refactoring main.js. Fork, Refactor & Test, Merge, Freeze & Test, complete!
Thirdly, according to the TODO list again... the mod_rewrite task is another "better to have first". It makes the codes look much better to understand. This task is pretty strict forward. Design the pattern, write the regular expression on apache conf (.htaccess could be the choice). And then, reflects the changes in both php and js. It's totally different from refactoring, no forking and no code freezing.
Finally, if there's still plenty of time, I would like to propose that the modified but not-yet-saved file should have a lock or google-doc alike collaborative editing. When someone is editing a file with file-based locking, others cannot edit it at the same time before the file is commited (lock released). This reduce the chance of having conflict in modification. If collaborative editing is considered, high level DocBook xml-tag locking can be considered. This means ... partly locking the file so that anyone can edit different parts of the same file. When conflict occur, notify the editors. This would be another busy task.
Community Bonding Period - Study current PhD OE architecture. Confirm refactoring procedures and exact deliverables with mentor.
May 23 ~ June 20 [around 4 man week] - Refactor & Test main.js
June 20 ~ June 27 [around 1 man week] - Merge Refactored code with trunk + Testing + Documentation
June 27 ~ July 4 - [around 1 man week] - Compile interim report
July 4 ~ July 18 [around to 3 man week] - Refactor & Test class.php
July 18 ~ July 25 [around 1 man week] - Merge Refactored code with trunk + Testing + Documentation
July 25 ~ August 15 [around 3 man week] - Implement mod_rewrite, reflect changes in php and js + Testing + Documentation
August 15 onwards - Compiling final report
Category (PHP, PELC, PEAR, other): PHP Manual
Wednesday, April 01, 2009
今日在填 MPhil Application ... 到了 Grad School 一遊, 實在是有感而發 ....
職業無分貴賤 .. 是真的嗎 !?