福茲提克資訊科技網

這兩天寫了一些Python，不得不佩服Java和PHP的文件。Python的文件不能說差，但是不好用、不好查。比如說我想查is這個keyword是什麼意思，最好我會知道他是列在Comparison啦。為什麼is不列在operator，這我不懂，明明==等都是啊。然後是例外處理，最好是我會知道有個sys.exc_info()啦。都查了很久才找到。

Python的官方文件主要分為Tutorial, Library Reference, Language Reference三塊，但他們的Table of Content都只有一個，而且TOC的標題不太能反映想找的內容。像Java、PHP、Ruby的文件都會切成幾個窗格，或至少有sidebar讓你點，我終於知道原因了，就是這樣才好用啊。還有簡單卻實用的示例也是很重要的，這點PHP做得不錯。

script /tmp/upgrade-hardy
sudo aptitude install update-manager-core
sudo do-release-upgrade

script是錄影用指令（這指令真難記，很容易混淆的名字）。錄影完打exit跳出。

剛剛試用了flickr video，我傳了一隻我在畢業典禮上，用Fuji數位相機拍的avi影片。結果上傳失敗，flickr說：請你重傳一次。囧。

算是舊消息了，根據JRuby開發者Charles Nutter這篇文章Welcome Pythonistas to Sun! ，Sun雇用了Frank Wierzbicki及Ted Leung來開發Jython及Python，就和2006年9月Sun雇用JRuby開發者一樣。目前JVM上面的主要語言，除了Java之外，還有Ruby (JRbuy)、Python (Jython)、JavaScript (Rhino)，以及JVM原生的scripting語言Groovy。

看來Java平台未來發展的重點之一是scripting語言。有了Python及Ruby這兩強加入，似乎也意味著Groovy是註定來不及長大了。

昨天寫了一段javascript code，在Firefox跑，一切正常；到IE不能跑。用Microsoft Script Editor來debug，雖然可以知道錯誤發生在哪一段程式，但是看了半天卻看不出錯誤在哪。後來只好死馬當活馬醫，用trial and error方法，把code隨意改一改。結果發現：咦，把相關的HTML element id改掉，似乎程式就不會卡住了。難道是IE對我的id命名有意見？

再定睛一看，會卡住的code剛好都是javascript variable和HTML id取名一樣的。原來，在IE裡javascript variable的名字不能和HTML id一樣！？再做了一些實驗，原來IE會把每個有id的element當作javascript的global variable，讓你直接用id/name存取DOM，而不必透過getElementById()。

這真的很討厭。我看到有國外的網站稱之為global namespace pollution。

自從用過Ruby之後，對它的Array唸唸不忘，Array#each是好物啊，有了它，幾乎可以把迴圈for/foreach給丟掉了。看了《Bring some Ruby/Prototype flavour in your PHP array》之後，心想PHP5也能這樣玩，真是讚，不用在PHP/Ruby之間的抉擇天人交戰了，把Ruby的語法移植到PHP來，這樣不就可以同時擁有PHP的廣大群眾，又擁有寫Ruby語法的簡潔／美麗／爽度了嗎？Prototype.js也是這樣做的，雖然《Learning Javascript》書中嚴厲反對Prototype.js破壞了javascript當中Array和for..in的組合技，但是Prototype.js的作者們顯然不在乎這點，照樣蠻幹。另還有《JavaScript “Associative Arrays” Considered Harmful》一文認為JavaScript當中的Array本來就不該當作associative array(hash)來用，所以組合技被破壞不算Prototype.js的錯。我個人的看法：說真的，有了Array.each，誰還需要for..in/foreach呢？

但是現實是殘酷的，由於PHP沒有anonymous function（幹，PHP根本什麼都沒有嘛！），所以callback無法像JavaScript或Ruby寫得那麼漂亮。或許應該說，雖然PHP語言特性貧乏，原本的目的是內嵌在HTML裡，卻能長到這麼大，也代表著PHP切合了初級web開發的需求，打入了一個很大的市場。《Bring》文中class的名稱是ExtendedArrayObject，只實作了部分method，但是我想乾脆把整個Ruby Array class實作好了。為了符合PHP的習慣，可以再定義一個xarray() function，x代表extended，用法類似array()（PHP的array()是language construct，不是function），只是回傳ExtendedArrayObject（factory pattern!?）。

神奇的是，我用Google搜尋xarray，居然找到我想做的東西，已經有人做過了！它是模仿Prototype.js的，也叫做xarray，而且是BSD license。但是不幸的是，事情總是沒有那麼順利，這個phpclasses.org要註冊才能下載東西，我又不想註冊。所以……我想我還是有空的時候來自己實作看看好了，當作練功！

INN (InterNetNews)是一個網路新聞群組的軟體套件。

sudo aptitude update
sudo aptitude install inn2

Ubuntu上可以用aptitude直接安裝INN，但要注意的是，套件名稱是inn2（代表INN 2.x版），套件inn是舊版的。

如果安裝到一半失敗，看看訊息是否是inn.conf檔沒設定好。如果是，你可能必須編輯它，將domain設為你的主機的FQDN。

sudo nano /etc/news/inn.conf

grep REGULAR_EXPRESSION `find DIRECTORY -name '*.EXT' -print`

指令組合分析：

• grep REGULAR_EXPRESSION FILE


• ``（反引號，backquote）：將find指令的stand output轉成命令列上grep動詞的FILE受詞


• find DIRECTORY -name 'FILE' -print：FILE兩旁是普通單引號

最近Yahoo!新聞一直在主打心情功能。每次看到文章上方寫著「看完新聞來表達心情」的標語，讓人又想哭又想笑。為什麼每一頁都需要這個標語呢？因為心情功能是沒有必要的、是不自然的、是違反常識的、是設計不良的、是容易忽略的，所以才需要這個提醒。分享心情的方式可以有許多種，到部落格分享心情、到PTT黑特板分享心情、用MSN即時通訊分享心情、打電話分享心情，但是絕對不是在看新聞的時候分享心情。原因很簡單：閱讀新聞的主要目的是吸收資訊，而不是情感表達，在閱讀新聞時表達心情，並不符合人們的心理歷程。當然有些新聞會牽動讀者的情緒，但並不是每個新聞事件都是如此。

我對「看完新聞來表達心情」這個標語，有自己的想像。那是一個達不成上級所指派業績的工程師。上級說，我們的網站，要多加入一些功能，比如說那個Web 2.0、社會網路之類的東西。經過了一些神奇的集思廣益的過程，結論是希望加入心情功能。過了一段時間，由於這個主打功能沒有人用，被盯的工程師只好加上這個很愚蠢，但是（當每一頁都看得到它時）又很有暗示效果的句子。我猜這差不多就是事情的經過，一個很沒有Sense（雖然他知道怎樣為企業賺錢）的上級，以及某個想不出好文案的工程師。

我認為，閱讀新聞的時候，讀者要很小心。有時候新聞沒有告訴你的事情，比告訴你的事情重要得多。時時保持懷疑，多方求證。如果某則新聞只有一家媒體報導，要小心它的可靠性。有時候記者字面上的用詞過於誇大，你必須看穿這些用詞，找到真正的核心所在。小心地閱讀，思考新聞背後真正的意義。這樣你才不會被劣質媒體所蒙蔽。鼓勵看完新聞表達心情，我覺得是錯誤的。當人們對閱讀新聞的直覺反應，被訓練成情感表達——而不是獲取資訊並思考——人們很容易為一些表層的東西而激動，卻失去了深究的機會。

最讓我覺得這整個心情功能都很愚蠢的是：他們竟然還做了排行榜！你知道嗎，這個排行榜對讀者而言根本不能增加網站的價值。我所謂的增加價值，意思是，理想的狀態下，使用者看到了個好東西，於是他分享給另一些使用者，使得另一些使用者也受益。對讀者有好處的，才是增加了這個新聞網站的價值。那麼，請問我需要知道「本日第一無聊」的新聞作什麼？既然已經很無聊了，那就別拿它來佔版面了吧。不用麻煩了，不用麻煩了，讀者很忙的。另外一個讓我不解的是，為什麼要分享生氣呢？為什麼會想要把一篇看了會讓人生氣的文章「分享」給別人，讓別人也生氣呢？這不是在害人嗎？對讀者一點益處也沒有吧。

結論：這是個不知所謂的功能。

這是我今年聽過最酷的事情！Jimbo，你太了不起了！

首先要說明的是：在現有的GFDL之下，wikipedia是無法轉用CC的。原因是GFDL要求他的衍生版本也在GFDL授權之下，而FSF（自由軟體基金會）雖然認同CC-by-sa的「精神」和GFDL相同，但是法律條文的細節卻造成了兩者實質上不相容。

CC組織其實在約2005年就注意到這問題，也努力在促進兩者的相容性，但事情一直沒有進展。所謂的Share-alike（相同方式分享），來自於FSF所推動的 'copyleft' 觀念。在早期的CC條款裡，衍生作品必須使用同樣的CC條款，也就是說，CC-by-sa的作品，無法改用GFDL授權。（除非所有原作者同意）

在CC-by-sa 3.0起，導入了新的相容性機制，CC-by-sa的衍生作品可以更改成CC組織所認可的授權方式。這有什麼影響呢？如果有兩篇文章，一篇是GFDL，另一篇是CC-by-sa；你想把其中一篇的部分文字截取，放到另一篇，可以嗎？在CC 3.0之前這是不行的（除非在合理使用下的引用）。因為GFDL的文字要求合成後需要用GFDL，不可以用CC-by-sa；而CC-by-sa（3.0以前）的文字要求合成後需要用CC-by-sa，不可以用GFDL。CC 3.0版之後，達成了單向相容，你可以把兩篇合成之後，改用GFDL授權。

Jimbo所公佈的這件事情，對我而言最重要的是，FSF的代表出席並同意了修改GFDL，讓GFDL的作品也可以改用CC-by-sa授權——這就代表了「雙向相容」的來臨，兩種最大的文件copyleft授權條款，彼此都可以任何更改成對方的授權方式。 可以說，在某種意義上，這使得作品更加「自由」了，創作者也不用採取像GFDL/CC-by-sa雙授權這種麻煩的方式。 如同Jimbo所說，GFDL的確是一個好的授權條款，但是他當初所設計的目的還是為了應用在程式文件上。「恆常章節」、「透明版本」、「最後修改的5個人」等較為複雜的設計，卻讓使用者在應用時會遭受到一些小麻煩（雖然不是不可解決）。我認為CC-by-sa對於使用者而言是相對方便的，由其是在小量（印出單一條目）的使用情況下。

這是一個很大的進步，受惠的不只Wikipedia，而是所有採用CC-by-sa及GFDL的創作者。

※本文採用CC-by-sa授權條款。