Heute morgen starb Pina Bausch, die Tänzerin und Choreographin des Wuppertaler Tanztheaters. Ein unerwarteter schneller Tod ergriff sie fünf Tage nach einer Krebsdiagnose. Noch am vorletzten Sonntag stand sie mit ihrer Company im Wuppertaler Opernhaus auf der Bühne.

（烏帕塔舞蹈劇場的舞者及編舞者 Pina Bausch 今天 [2009年6月30日] 過世了。五天前她才剛做完癌症檢查，就這樣意外地匆匆過世。上上星期天，她還與她的舞者們一同站在烏帕塔歌劇院的舞台上。）

所以意圖 (intention) 有兩個部分：「為什麼」採取現在的手段，以及「為什麼不」採取其他各種可能存在的手段。

程式教材的文字為什麼往往比 code 要長上數十、甚至數百倍的原因就在這裡。另一方面，這也就是為什麼抄襲跟模仿不容易達到跟原創一樣結果的原因：因為前兩者都只看到了既存的結果，而沒有辦法體現出原創所採取（以及所不採取）路徑所意欲解決的問題──而那些問題很可能因為原創的出現而消失，使得抄襲模仿者甚至無法察覺問題的存在。

1. 如果您選擇了一段報表日期，但這一段日期沒有任何資料存在
2. 如果您先前曾經刪掉過某個分類 (category)，還有資料使用這個已經不存在的分類，產生報表時正好其中有這樣的資料

上述情況很可能造成 TapExpense 當掉，且無法繼續使用。2.2.1 修正了這個問題。

這次要感謝幾位使用者，他們用了很多時間測試跟確認 2.2 的問題來源，還提供了 crash log 給我們做診斷。先前因為程式的 bug 造成大家的不便，在這裡也要跟大家說聲不好意思！

建議大家升級到 2.2.1 （既有的使用者升級是完全免費的）。

另外 TapExpense 的 Lite 版本目前還在 Apple 那裡審核，希望近期也能順利上架。

附帶一提，TapExpense 從 2.0 開始也有了自己的討論區 ，討論區每個月會自動整理存檔。歡迎大家利用討論區來提出意見和交流。當然，如果有任何的問題或者建議，也歡迎大家發信給 service {小老鼠} lithoglyph {一點} com 讓我們知道。

謝謝！

2009年5月17台灣版《蘋果日報》的新聞：

環保署長沈世宏今天全程參與一項民間團體辦的廁所清掃活動後表示，今年度列管考核全國1萬7000多所公共廁所，明年將擴大到3萬6000所，並將融合應用今日所學的清掃方法與精神。

美化日本協會推廣清掃廁所影響，台灣美化協會在台灣推動清掃廁所已7年，在今年年度大會系列活動中，發動全國57個分會動員上萬人於今天在全國各地清掃廁所，沈世宏是在台北市葫蘆國小參與清掃廁所。

協會指出，近1000人上午到葫蘆國小，在流程解說、任務分工後，進入廁所各自工作崗位，在小組長與日本顧問協助下認真清掃藏污納垢的馬桶，洗手台、天花板、牆壁、燈管、鏡子也不放過，發揮徹底學習精神。

沈世宏全程參與2小時的清掃過程後，有感而發表示，世界要美麗，要靠每一個人。清掃學習注重細節，體驗凡事徹底，過程處處是學習，讓人成長，完成後更充滿成就感，未來要將這種精神擴散到各鄉里城鎮。

我的舊文〈大老闆們，別再洗廁所了！〉：

有沒有可能設計出「比較不容易髒」的廁所？有沒有不那麼痛苦的廁所清潔法？為什麼大家還在用10元一支的塑膠掃把、拖沒幾次就斷頭的拖把在掃地、拖地？掃地一定得一整班人鬧哄哄地掃，沒有更優雅的輪班分時分工制？所以，親愛的大老闆們，請你們別再掃廁所了！請你們找點別的事情，消耗平日吃太多所屯積的脂肪。掃廁所這件事情，就請動動你們搞cost-down時的精明腦袋，為我們的環境品質做點好事吧！

吳聰敏，〈有味道的廁所〉（粗體字為我所加）：

台灣的學生須打掃校園，其中包括廁所。學校的廁所不乾淨，有味道，原因是廁所是由學生打掃。被分派到的學生只覺得倒楣，並沒有把它打掃乾淨的誘因 [...]

小孩在公立學校上課，家長透過納稅繳了大筆學費。學校要學生掃廁所，這好比是麥當勞或百貨公司的老闆，要求客人清掃顧客以及員工的廁所。而且，員工的廁所必須更乾淨！有人認為，打掃是生活教育的一部分。從這個角度來看，掃廁所的目的應該是希望學生能養成好習慣，回到在家裡也能幫忙整理環境。不過，我很懷疑全台灣到底有多少學生在家裡會幫忙刷馬桶的。我同意生活教育重要，但由實施結果來看，我看不出來掃廁所是有意義的生活教育。更嚴重的是，這個制度可能對某些學生的健康有不好的影響。

廁所問題如何解決？最簡單的答案是廁所清潔工作外包，不要再由學生來清掃。這樣會讓學校的廁所乾淨一些。但我相信清潔工作外包之後，老師的廁所仍然會比學生的乾淨。我小孩所上的民間經營的安親班，學生與老師使用同一廁所，同樣乾淨。百貨公司或餐廳裡，也是如此。因此，我認為讓學校之間有競爭才是解決廁所問題的有效方法。

Seasons (浜崎あゆみ)

今年もひとつ季節が巡って
思い出はまた遠くなった
曖昧だった夢と現実の
境界線は濃くなった

それでもいつか君に話した
夢に嘘はひとつもなかった
La La-i

今日がとても楽しいと
明日もきっと楽しくて
そんな日々が続いてく
そう思っていたあの頃

繰り返してく毎日に少し
物足りなさを感じながら

不自然な時代のせいだよと
先回りして諦めていた
La La-i

今日がとても悲しくて
明日もしも泣いていても
そんな日々もあったねと
笑える日が来るだろう

幾度巡り巡りゆく
限りある季節(とき)の中に
僕らは今生きていて
そして何を見つけるだろう

以下是很久沒寫的生鏽 Perl ，惡名昭彰的 one-liner 。把樂多留言板內容存到某個 sample.txt 裡面，然後：


cat sample.txt | perl -e 'while (<>) { $c{$1}++ if /Posted by (.+?) at.+\d\d\d\d/ } for $k (keys %c) { push @a, [$c{$k}, $k] } for $p (sort { $b->[0] <=> $a->[0] }@a ) { print "$p->[1]: $p->[0]\n" }'


於是就會 dump 出：

lakatos: 136
白玫瑰: 64
Richter: 55
ricebug: 54
盤: 53

（這樣夠明顯是哪個 blog 了吧）

不過竟然還寫得這麼長顯然是沒有辦法從事任何 Perl 競賽的（笑）。

系統預設的 didReceiveMemoryWarning 實作（你一定用得到，因為你得呼叫 [super didReceiveMemoryWarning]）是，如果當前 controller 所擁有的 view 沒有其他 superview （通常代表意思是沒被顯示出來，例如，埋藏在 navigation chain 或其他 tab 當中），那這個 view object 就會被是放掉。

如果你的 controller 只有這個 view 物件，事情就到此為止。不過我們都知道人生從來不是這麼簡單的。

尤其，如果你的 controller 當中宣告了從 nib 載入了 IBOutlet 物件。根據 Apple 文件，xib 載入的時候所有的 IBOutlet 物件都已經至少有了 retain count 1 。這些物件通常也都被你的 view 物件所擁有，所以通常等你用到他們的時候，他們的 retain count 都至少是 2 。

但是你的 view object 被放掉時，這些 IBOutlet 還被 retain 著。所以你要做兩件事：

1. 在 view 被放掉時，也同樣放掉你的 IBOutlet
2. 在你的 controller 被 dealloc 到時，也放掉你的 IBOutlet ，同時將他們的 pointer 設到 nil

iPhone SDK 一直到 2.2.1 都沒有好方法讓你做到 1. ，所以請參考 Craig Hockenberry 的這篇文章 ，簡言之就是要去 override -[UIViewController setView:] 才有辦法在 view 被放掉時也同時放掉那些 IBOutlet。

（雖然事實上，如果你照著 Apple 最新的 coding 規範，將 IBOutlet 都設為 readwrite retain property，那麼在你的 controller 下次再度載入 view 時，這些舊 IBOutlet 都會被放掉，但是呢，如果你的 IBOutlet 很肥，例如滾輪式選單，那麼最好是放掉他們）

然後呢，在你的 controller 要被 dealloc 的時候，記得放掉你的 IBOutlet 物件，同時將指標設到 nil。Apple 文件有說明原因：因為當你最後呼叫 [super dealloc] 的時候，你的 view object 會被放掉，然後如果你已經做了 1. ，view 被放掉時去釋放 IBOutlet，偏偏你早就已經在 dealloc method 前半部 release 了他們，那麼接下來就會有人對死掉的指標值（所謂的「當夠了物件」──dangling object）送出 release 訊息，那就爆炸了…

總之，iPhone app 在記憶體使用上的最高指導原則是 lazy loading。要用的時候才載入，不用的時候就放掉且將指標值設為 nil ，最不容易出錯。這也是 Apple 從 Objective-C 2.0 時代開始大量推薦使用 @property 的另一個原因。