顯示具有 Blog 標籤的文章。 顯示所有文章
顯示具有 Blog 標籤的文章。 顯示所有文章

2009年8月10日 星期一

《別鬧了,費曼先生》閱讀中的雜記

讀《別鬧了,費曼先生》的過程裡,偶而有寫片段感想。這篇是這些短記整理後的記錄。

通用的學習法則

《別鬧了,費曼先生》提到費曼常跨領域學些不同東西,不管是哲學、數學、生物學,費曼都用他學習科學的習慣判別對錯,掌握基本原理。最近做研究也有這種體會。即使沒有背景知識,有良好邏輯,掌握假設和觀察結果,通常能做出正確的判斷。前提是我們能明確判讀那些是客觀事實,那些是主觀判斷,數據不會騙人,可是人會,而且我們自己也可能會騙自己。

舉例來說,看到別人的實驗結果和實驗報告,一定要自己讀一遍數據,不然無法判斷別人說明中那些部份為主觀推測。像是兩個方法有效程度差了千分之一,是否可說有顯著差異?去除人有私心的因素外,我們也沒有想像中的聰明,容易將一些相似的資訊混在一起,不知不覺認定是事實。「誤把有相關性視為有因果關係」是常見的例子,有興趣的人可以看些寫給大眾看的統計書籍。反用「判讀個人觀點和事實」的原則在自己身上也很有效,可以找到自己思路的盲點,不會過於武斷主張自己的看法。

此外,舉例說明是最佳的討論方式。費曼提到他和數學家討論數學原理時,他的判斷方式是心中想像一些實例,對方描述問題時,他就想像心裡那些物體會怎麼變化,於是當對方說某某性質如何,他發覺在他想像世界裡有矛盾時,就能做出辯駁。另一方面,我相信只有當我們能舉例說明時,我們才算真的明白,藉由逼自己舉例,可以思考的更靈活,找出忽略的細節。

別死記名詞

另一方面,費曼也指出許多人記了一堆名詞,卻沒掌握基本精神,他在 MIT 的大學同學如此,愛因斯坦的研究助理也會犯這種錯。費曼一再提到很多學生只會背名詞,不會理解背後的含意,不明白他們在學什麼。這種精神從他小時候就存在,和父親在林中散步時,費曼的父親向他解釋生物行為而不背名字,費曼將自己的成就歸功於父親童年時的教導,不無道理。

費曼在問學生問題時,會舉例討論,而不問教科書式的問題。我在確認別人能力時也是這麼做,不問專有名詞解釋(像是請說明 X 演算法為何),盡量用應用題直接看對方怎麼運用知識,這樣能立即明白對方有沒有理解背後含意。反過來看,不知道某些名詞不代表什麼,就算對方不知道 Dijkstra’s Algorithm,但若能提出相似的解法,反而更高明。只要和對方說明這些知識,他們立即能掌握精神加以運用。反之,知道 Dijkstra’s Algorithm 卻無法活用,知道更多演算法、累積更多經驗,成長也有限。

名詞只是方便溝通的工具,若不能理解背後的含意,光記許多名詞毫無意義。在資訊爆炸的時代,每天產生一堆新的名詞,吸收這堆雜亂的詞彙時,得時時提醒自己,是否明白背後含意。以前我曾落入背誦知識為樂的陷阱,後來發現知道很多皮毛卻無法做進一步運用,才驚覺自己浪費不少時間。舉例來說,現在當紅的 Android,即使我知道 Android 是 Google 發佈的手機平台,也沒任何幫助,只是一堆名詞堆砌。到不如了解為何會有 Android?適合解什麼樣的問題?需要時可視需求對相關知識做進一步研究。 (備註:我並不了解這兩個問題,只是舉例而已。)

並不是說記名詞毫無意義,費曼童年時自己發明一套數學符號,他覺得讀起來比較好理解,很高興地用了一陣子。但後來發現他無法和人溝通,就把這些符號丟了,改用共通符號。與人溝通需要專有名詞,不然難以進入問題核心,講半天還在說「你是說如果有 n 個點,點可以是任意東西,像是城市,或想像成座標也行,這 n 個點之中部份兩點有互相連接,連接的距離長短不一,而你想從某個起點 A 走到終點 B,想問如何走才能花最少的步數嗎?」(即最短路徑問題)。

2009年4月25日 星期六

寫 Blog 好幫手 TD-Post!

為了方便寫 Blog,寫了個小程式讀 wiki code 產生 WordPress 吃的格式,順便藉機練習 TDD,沒想到寫了十小時才完成。剛好最近在看虎x龍的動畫,就將它命名為TD-Post (Tiger x Dragon Post) 吧。

緣起

換過多家 WordPress 用的編輯器後,我還是找不到滿意的工具。為縮短寫 Blog 的時間,我決定自己做一個。

寫 Blog 最惱人的事有幾點:

  1. 得輸入麻煩的 HTML,特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀,改文章時很不方便。
  2. 加超鏈結很麻煩,常用的幾個超鏈結,得重附貼多次,像 TDD 我就重貼了許多次。
  3. 無法用自己慣用的編輯器。若能用 Vim 寫 Blog,速度必能大增啊!

功能簡介

對我來說,寫 wiki code 相當方便,所以輸入格式決定用 wiki code。但 wiki 格式有許多種,我比較常用的有 PmWikiDokuWikiTWiki,其中以 PmWiki 語法最簡單,但原始碼沒後兩者好讀。最後聽從 York 的建議,採用 Tracwiki 格式。選它的主要原因除好讀好寫外,我特別喜歡它 Preformatted Text 的格式,很適合用來貼程式碼。

接著,針對第二點問題,加上自動補超鏈結的功能,只要寫過一次超鏈結,TD-Post 就會自動記下來,自動補上對應的位置。像在這段裡,因為我在第一段已寫過 TD-Post 的位置, TD-Post 的超鏈結都會自動補上。初步估計,以後寫一篇 Blog 至少可以省十分鐘,所以差不多用個六十次...這幾天的辛勞就.就回本啦。

程式下載

本程式採 BSD License ( 簡單說就是隨便使用 ),歡迎大家玩玩。雖然沒什麼註解,但我照 TDD 流程寫的,測試碼應該很完整。這裡是一些相關資訊:

  • 下載:http://code.google.com/p/td-post/downloads/list
  • 程式語言:Python
  • 程式碼總行數:682 行
  • 測式碼:346 行 ( 主要是準備測試的例子 )
  • 非測試碼:336 行
  • 實作時間:原本預估兩小時完成,卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突,這部份從開始實作到結束花了三小時才解決。

其它

有原始碼有真相,最後附上本文的原始碼:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
為了方便寫 Blog,寫了個小程式讀 wiki code 產生 [http://wordpress.org/ WordPress] 吃的格式,順便藉機練習 [http://en.wikipedia.org/wiki/Test-driven_development TDD],沒想到寫了十小時才完成。剛好最近在看[http://zh.wikipedia.org/wiki/虎與龍_(小說) 虎x龍]的動畫,就將它命名為[http://code.google.com/p/td-post/ TD-Post] (Tiger x Dragon Post) 吧。
 
==== 緣起 ====
換過多家 [WordPress] 用的編輯器後,我還是找不到滿意的工具。為縮短寫 Blog 的時間,我決定自己做一個。
 
寫 Blog 最惱人的事有幾點:
 1. 得輸入麻煩的 HTML,特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀,改文章時很不方便。
 1. 加超鏈結很麻煩,常用的幾個超鏈結,得重附貼多次,像 [TDD] 我就重貼了許多次。
 1. 無法用自己慣用的編輯器。若能用 [http://www.vim.org/ Vim] 寫 Blog,速度必能大增啊!
 
==== 功能簡介 ====
對我來說,寫 wiki code 相當方便,所以輸入格式決定用 wiki code。但 wiki 格式有許多種,我比較常用的有 [http://www.pmwiki.org/ PmWiki]、[http://www.dokuwiki.org/ DokuWiki]、[http://twiki.org/ TWiki],其中以 [PmWiki] 語法最簡單,但原始碼沒後兩者好讀。最後聽從 York 的建議,採用 [http://trac.edgewall.org/ Trac] 的 [http://trac.edgewall.org/wiki/WikiFormatting wiki 格式]。選它的主要原因除好讀好寫外,我特別喜歡它 Preformatted Text 的格式,很適合用來貼程式碼。
 
接著,針對第二點問題,加上自動補超鏈結的功能,只要寫過一次超鏈結,[TD-Post] 就會自動記下來,自動補上對應的位置。像在這段裡,因為我在第一段已寫過 [TD-Post] 的位置, [TD-Post] 的超鏈結都會自動補上。初步估計,以後寫一篇 Blog 至少可以省十分鐘,所以差不多用個六十次...這幾天的辛勞就.就回本啦。
 
==== 程式下載 ====
本程式採 [http://zh.wikipedia.org/w/index.php?title=BSD许可证&variant=zh-tw BSD License] ( 簡單說就是隨便使用 ),歡迎大家玩玩。雖然沒什麼註解,但我照 [TDD] 流程寫的,測試碼應該很完整。這裡是一些相關資訊:
 * 下載:http://code.google.com/p/td-post/downloads/list
 * 程式語言:[http://www.python.org/ Python]
 * 程式碼總行數:682 行
 * 測式碼:346 行 ( 主要是準備測試的例子 )
 * 非測試碼:336 行
 * 實作時間:原本預估兩小時完成,卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突,這部份從開始實作到結束花了三小時才解決。
 
==== 其它 ====
 
有原始碼有真相,最後附上本文的原始碼:{{{
#!html
_QUINE_
}}}
 
身為資工人,這段原始碼當然也是自動貼上的啦,不過我沒用像 [http://en.wikipedia.org/wiki/Quine_(computing) Quine] 那樣的技巧,只是單純地取代關鍵字。

身為資工人,這段原始碼當然也是自動貼上的啦,不過我沒用像 Quine 那樣的技巧,只是單純地取代關鍵字。

2009年3月8日 星期日

裝了 ScribeFire Blog Editor

由於 Windows Live Editor 對 WordPress 的支援不夠完整,這篇改用 Scribefire 試看看。

Scribefire 也有很炫的預覽功能,而且多了可以將網頁的標題和連結取出加入編輯內容內,挺方便的。Category 部份到是有支援一半,可點選要加入那些目錄,但沒有顯示出原本目錄的階層關係。唯一的缺點是不能加入<!–more–>。或許之後可以改用 ScribeFire 看看。

Update

ScribeFire 也加了部份討厭的 tag,像是 <br> 和 <div>,這樣日後要回頭手動編輯時,文章內容挺醜的。

裝了 Windows Live Writer

剛才不小心關掉網頁而遺失了正在寫的文章,一怒之下就裝了 Windows Live Writer。現在這篇就是用它來試寫。

初步用起來還挺方便的,不過每打一個字畫面就閃一下,感覺挺怪的。還有不能插入 WordPress 專用的一些 tag,得自己切到 Source mode 輸入(例如<!—more—>)。 Preview mode 看起來挺屌的,可以直接看到文章送出後,在自己的 Blog theme 下看起來是什麼樣子。

Update

Windows Live Writer 竟然加了多餘的 tag,像是 <p>,而且不能用<!—more—>,發文章時找不到選 category 的地方,只有看到加 tag。改來試用別套好了。

2009年1月25日 星期日

修改 One year ago plugin

效果見本篇文章下方,剛好去年和前年的今天有發文章。

原本 plugin 可從這裡下載 。我把輸出格式改成條列式,並把每年同一天的文章都取出來(原本是取出過去每年同一天的文章)。改完的檔案可從這裡下載

幾篇文章不小心變 private post

用 WordPress 2.7 才發現,幸好有 quick edit,很輕鬆地把它們設為 public。Po這篇另一個目的是要測 One Year Ago 的 plugin XD。

2009年1月24日 星期六

更新 WordPress!

看了 WordPress 2.7 的介紹後超心動的,趁過年回家陪爸媽看電視的時間來更新!

與其說是更新,不如說是砍掉重練吧。舊的 plugin 全丟掉,反正重要的也只有那幾個,為了省事,重找和 2.7 相容的 plugin 比較方便。新版面看來還不壞,後台又超好用的,留言速度好像有比較快(還是我的錯覺 XD)。看看之後回新竹時能不能把欠一堆的文章慢慢補齊吧。

文末來測一下常用標籤的外觀吧

我是 H3

我是 H4

很久很久以前寫的片段 python code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import sys
 
def decode(n, len):
        """Hello, this is document string. Happy Chinese new year!!."""
        input = []
        for i in range(0, len, 1):
                if n & (1< <i) != 0:
                        input.append(1)
                else:
                        input.append(0)
        return input
# No comment.
# No comment.
# No comment.
 
if len(sys.argv) > 1:
        print sys.argv[1]
        print simulate(int(sys.argv[1]))
else:
        print simulate(1)

順便來測圖,有圖有真相(公司發的年終禮物...,裡面是柳丁):
5 kg oranges

最後是大概不會用到的表格:

head head
ohoh data ohoh data

2009年1月11日 星期日

知識管理工具 (3)

( 前兩篇見這裡:第一篇第二篇。)

最近的使用習慣變成 Google Notebook + Dokuwiki + BBS + Plurk。。

我對工具的基本要求是在任何地方都可以存取以及容易備份,再來是考量輸入和閱讀的便利性,以及資訊的流通性。這四項工具中,Google Notebook 和 DokuWiki 是方便個人維護知識,但流通性差,不易和其他人互動,自然也難以得到回饋;後兩者則相反。下面各別簡介我的用法:

  • Google Notebook 操作超方便的,記錄條列式訊息比 Wiki 還方便,會自動存檔,按 Tab/Shift+Tab 可以 加深/減少 條列項目的層級,可以輕易地管理權限和分享給限定的人士。用來存暫時用到的資料,如待看書單、未整理清楚的隨手筆記、todo list。
  • 自己架的 DokuWiki 則是存技術性文章(像是架 server、Unix commands、programming language 筆記),供日後方便索引。Wiki 的好處是版面排列彈性極大,可視需求附加功能,方便貼 code,並含 syntax color。DokuWiki 的預設顯示和編輯介面,可說是我用過的系統裡最棒的(其它用過的有 Google SitePmWikiTWiki)!不需做任何更動即有 section editing、code syntax、以及簡單好用的編輯介面。加上是 text file db,把整個目錄 tar 起來就能備份。
  • 我一直覺得 BBS 是個很怪的平台,相當不適合儲存資訊,但它的極快操作和極簡單的閱讀介面卻是 Web 目前無法取代的。我用 BBS 存粗糙的心得,日後也能回頭索引,還有能和其他人分享及得到回饋。
  • Plurk 是最近剛開始玩的,真是理想的碎碎念平台,輕易地和分散各地的朋友串起來。類似 IRC 的感覺,不過是每人各自形成一個聊天室,使用者可同時看到所有訂閱的「聊天室」內的訊息匯入自己看的頁面。加上簡單易用的介面,輕楚的時間軸表示,比 IRC 親切多了。好處是當有疑問想請問朋友,卻不知問誰時,可以輕易地和所有人待上線。目前似乎沒有搜尋訊息的功能,有的話就方便存片段資訊了。

至於以上沒提的 Blog,仍然用來做為整理長期整合的心得,或是記錄人生的片段。除非極有分享的必要(例如網路上很少這類資訊),或是較適合文章形式的表現,才會寫在這裡吧。而 bookmark 部份,我已很少用 delicious 了,原因是存取不夠迅速,我覺得 bookmark 應該要像本機 browser 存取一般才適用。目前暫時改用 Google Bookmarks ,裝 Google Toolbar 後就可取存,介面雖然簡單,操作卻相當快速。由於我很少會回頭點 bookmark,反而較常點存在 Google Notebook 和 Wiki 裡的超鏈結,暫時還不確定怎麼維護 bookmarks 較適當。

2007年5月2日 星期三

知識管理:bbs, wiki, blog, bookmark (2)

上篇為《知識管理:bbs, wiki, blog, bookmark》,前陣子有學弟開始用Wiki,於是來分享近來的使用心得。

這篇重點在寫文章和工具的用法,一樣工具,隨著目的不同,用法會不同,寫文章(筆記)前要先決定讀者為何,這點明確定位後,工具用起來就會很順,反之,定位不清,寫起來只會綁手綁腳。

我目前的心得是bbs,wiki,blog,bookmark都會用到,我的心得不是工具的功能有多強,而是我對這些工具的定位更清楚了,下面描述的都是我的用法,不代表它們就是這麼用的。

使用工具前要先確保兩個重要功能:
1. 全文搜尋
2. 多重分類 (or tag)

再來的議題有:
1. 流通性 (傳播能力,有RSS者較佳)
2. 備份的便利度

比方Blog上述條件全符合,bbs完全不行,wiki的流通性不及Blog。

wiki是寫給自己看的,寫起來快速有組織即可,wiki適合條列編修,反覆修改,內文交互參照,很適合寫筆記和想法暫存,而且像DokuWiki有section editing和folding(plugin),以及headline的sidebar,在wiki page成長後仍保有top-down的可讀性。

lab合作時有用wiki當公告欄放想法,個人想法暫記再從公告頁內開子頁面寫,避免大家頻繁改wiki時造成衝突,試用的結果挺微妙的,似乎有點亂,但滿有用的 ( wiki的特性是可以翻頁面修改記錄,可得知何時誰做了那些改變 )。

blog的流通性最高,用來寫給大家看,寫起來最累,因為對象廣,文章要有組織性,要有背景說明 / 出處參照 / 相關探討 / 文章分類,寫blog有助於組織想法,這種組織和wiki不同,wiki寫給自己看,加上便於修改,組織性比較隨性,blog則有一定受限,像我寫blog摸索一陣子後,就很少開新分類,開一個分類表示我有心在那分類產生後續文章,我在寫blog時的自我要求比較多,像是盡量避免笑臉符號,盡量用通順文章的格式,加強正式表達能力。

bbs則是介於blog和wiki之間的用途,由於看bbs的大多為已認識的朋友,要feedback比較快,而且寫起來比較快,不像寫blog會很在意文章架構,在意語句和段落間的連接性。

bookmark網站的用法還在摸索中,目前只是當URL暫記,說來諷刺,我的研究方向是針對bookmark,但用的頻率最少。

以上不管那一種用法,都有滿多實驗空間,像是讀書心得,在寫成blog前可以放在wiki上暫記,累積到一定的量再集合成文章,但不知怎麼,就是覺得寫在bbs上較順,順便期待在寫成blog前能不能先得到feedback。

另外我覺得開不同的wiki站感覺也不錯,我目前有三個wiki,lab的PmWiki記研究想法,個人的PmWiki暫存舊的,短期間的東西,不在意資訊的組織性,個人的DokuWiki記新的想法,逐漸將wiki架構弄得更明確,最近看《資訊架構學》和《隨意搜尋》有些心得,覺得wiki可以有更多可能,再摸索看看。

另外配合GMail的label + filter可以做到不錯的合作溝通媒介,人多時可以考慮用Google Newsgroup,大家再用GMail訂閱,依我目前的試用情形,三人使用mail溝通很有效率,確保大家都能即時看到資料,重點是要用label + filter將信件自動分類。

如果溝通時需要有行程表之類的長時間記錄,可以考慮用newsgroup或wiki記下來,我傾向用wiki記。

2007年4月3日 星期二

test “google-code-prettify”

官網:google-code-prettify

這裡看到的,似乎還有些問題。我原本是用Code Auto Escape,功能陽春但還過得去的plugin。先繼續用Code Auto Escape吧。

Ruby

test ruby

#!/usr/local/bin/ruby exit if ARGV.length < 2 # read stop words stop = File.new(ARGV[0]) stop_words = Hash.new() while line = stop.gets line.split.each { |e| stop_words[e] = 1} end stop.close # read text text = File.new(ARGV[1]) count = Hash.new(0) while line = text.gets line.split.each { |e| count[e] += 1 if stop_words[e] == nil } end text.close # dump results count.keys.each { |key| puts "#{count[key]} #{key}" }

Java

test java
Table stopTable = buildStopWordTable(args[0]); // store String Table doc = new HashTableLL(); // store Count BufferedReader br = openFile(args[1]); String s; while ((s=br.readLine()) != null) { StringTokenizer stk = new StringTokenizer(s); while (stk.hasMoreTokens()) { s = stk.nextToken(); if (s.length() == 0 || stopTable.find(s) != null) continue; Count nc = new Count(s); Count c = (Count)doc.find(nc); if (c != null) c.count++; else { doc.add(nc); } } } br.close(); Iterator iterator = doc.getIterator(); while(iterator.hasNext()) { System.out.println(iterator.next()); }

2007年1月31日 星期三

WordPress Plugin:SyntaxHighlighter

官網

安裝、設定、使用都很容易,可是測試結果有問題,so sad。

Ruby

#!/usr/local/bin/ruby exit if ARGV.length < 2 # read stop words stop = File.new(ARGV[0]) stop_words = Hash.new() while line = stop.gets line.split.each { |e| stop_words[e] = 1} end stop.close # read text text = File.new(ARGV[1]) count = Hash.new(0) while line = text.gets line.split.each { |e| count[e] += 1 if stop_words[e] == nil } end text.close # dump results count.keys.each { |key| puts "#{count[key]} #{key}" }

Java

Table stopTable = buildStopWordTable(args[0]); // store String Table doc = new HashTableLL(); // store Count BufferedReader br = openFile(args[1]); String s; while ((s=br.readLine()) != null) { StringTokenizer stk = new StringTokenizer(s); while (stk.hasMoreTokens()) { s = stk.nextToken(); if (s.length() == 0 || stopTable.find(s) != null) continue; Count nc = new Count(s); Count c = (Count)doc.find(nc); if (c != null) c.count++; else { doc.add(nc); } } } br.close(); Iterator iterator = doc.getIterator(); while(iterator.hasNext()) { System.out.println(iterator.next()); }

2007年1月27日 星期六

用簡訊保持連繫

一個多月前寫了這篇”什麼樣才叫保持連繫呢?”,今天看到12月的Advanced,提到芬蘭國內有98%使用手機,只有一半使用固定式電話 (landline) 。有一位語言教師,用傳簡訊和親友保持連繫,週六時她通常要收發100封簡訊,並在晚餐時間左右再發40封,相當驚人,她個人則覺得沒有比這更好的連絡方式。的確,使用非同步式溝通,可以省去冗長的起頭和結束話,也不會不小心聊離題。

看到這個例子時,我想到的是大家都來寫Blog就好了,每個人都在對所有人說話,溝通效率更好 XD 。可能是熱於分享的性格所致,總覺得一再地對別人重覆同樣的話很浪費時間,到不如寫出來就能給所有人看到,有興趣的人來回言,其他有興趣的人也會看到,資訊通透對大家都好。唯一的缺點是不方便講悄悄話,有些話就是在小圈子裡才會吐出來 :P

2007年1月12日 星期五

推薦系列文章:”日本動畫產業舞台的前與後”

Blog推薦:IGT偵探趣味

應該不少人看過這個Blog,挑戰者月刊主編的個人Blog。常有許多擲地有聲的好文,最近站長開始介紹日本動畫產業,這麼簡單就能知道這些資訊,實在是很划算的事 :P

《日本動畫產業舞台的前與後:前言》:這篇前後有一系列文章,大家就自己翻翻吧。