MaoYang-有話要說

最近喜歡上了Google Reader , 原本是使用firefox的一個plugin叫Sage來管理我的RSS訂閱,但是Sage有一個缺點, 資料放在單一台電腦, 要分享與同步都很麻煩, 於是我開始使用Google Reader, 而且我相當喜歡Google Reader的分享功能, 這個分享功能有點類似funp.com推推王的推文功能, 但是比推推王簡單許多, 我寫了幾篇Howto 將Firefox的RSS訂閱工具改成Google Reader 透過Google Reader分享RSS訂閱的文章 所以會了這些等於你擁有個人的"推推王" , 如果要將這些個人的推文放到CodeBeamer ,這也很簡單, CodeBeamer從5.0.x版的Wiki開始支援HTML Plugin & Feed Plugin, 無論是透過HTML plugin將Google Reader所提供的分享項目 javascript code貼到Codebeamer的Wiki網頁, 或是透過Feed Plugin將google reader分享項目的RSS URL貼到wiki都可以, 以下Howto就是利用Feed Plugin將Feed嵌入到Wiki網頁 使用RSS Feed Plugin 這樣團隊的成員要分享推文是不是變簡單了! 而且這對產品開發團隊有非常大的幫助, 每個成員都可以幫助Marketing人員收集到不錯的Blog文章或是idea

剛才在看Object-C 2.0的新功能 @property 宣告, 其中談到了 thread-safe , 如果您有寫過Multi-Thread的程式, 甚至寫過device driver, 相信對於thread-safe應該不陌生, 而且當你的Object中的member variables同時會被兩個以上的thread所存取, 這時候thread-safe的觀念就很重要, 因為你的accessor會有funtion re-entry的問題, 當write function還沒結束, 另一個thread又呼叫了Object的write function , 你永遠無法確保記憶體中的資料完整性, 所以在Driver 的DDK 都會有文件特別說明如何用Lock來確保memory access的時候, 只有當一個thread完成write後, 另一個Thread才能繼續write, 我發現這個觀念不僅在multi-thread中受用, 在Google App Engine中的Big Table也受用, 在Google的簡報, 讓我印象最深刻的一句話-- Writing data to big table is expensive , 因為每一次write data, google app engine就會將這份資料duplicate到不同的Cloud server , 這時候問題來了, 當不同的使用者, 同時從不同的Client, 同時要update一筆位在Big Table中的同一筆資料, 這個狀況跟寫driver或是multi-thread同時去寫Object中的member variables一樣. 不過thread-safe除了資料的同時存取, 在GUI framework似乎還有另一層意義-->代表強制分時多工的thread, 我在幾年前開發過一個Peer to Peer 的Cocoa 程式, 當時遇到一個棘手的問題, 當使用者在操作GUI的時候(例如用滑鼠右鍵一直按Scroll Bar), 我這隻Cocoa程式的背景負責傳送資料的thread竟然會受Cocoa GUI元件影響而stop住, 我當時找了許多資料, 結果有國外的cocoa developer 社群就很多developer說這是因為Coc

Cocoa的Framework相當於Windows的DLL, 但是剛才在測一個third party的library, 想把它編譯成Framework給iPhone Application使用, 當使用Xcode add target的時候才發現原來Custom Framework在Cocoa touch還沒有support :-(, 這對於要開發share library給不同的Application使用的開發團隊真的很不方便, 只能將所有的source code放在一起編譯, 難道Apple認為iPhone的Application都是只有一個人獨立開發就能完成?

今天才發現Mac的Copy會將整個目錄給蓋掉, 例如 文件/目錄A/ 這個目錄有A.txt , B.txt 兩個檔案 測試文件/目錄A/這個目錄有A.txt, B.txt, C.txt 三個檔案 如果你將文件/目錄A 用drap & drop方式要將文件temp/目錄A給覆寫掉, 你猜會發生什麼事? 測試文件/目錄A/底下的C.txt會被刪除. 這個設計對Windows使用者可能會很困擾, 對Developer的我來說更是頭大 因為subversion的工作目錄下有個隱藏目錄.svn非常重要, 如果我要將工作目錄下某個library置換成新版, subversion client會發出哀號說找不到.svn目錄. 解決方法, 進入終端機使用cp指令 cp -iR source target i = prompt 可以省略 R = Recursive 這個討論串也有談到其他solution , 不過要花錢, 應該要建議apple在copy時加一個Merge的選項才對 http://discussions.apple.com/thread.jspa?messageID=7831429

在我待過幾家公司推導Issue Traking工具, 和幫CodeBeamer客戶推導Issue Tracking的經驗, 最讓我困擾,也是專案經理困擾的一件事就是寫comment這件事, 因為大家都已經習慣使用E-Mail, 而且當收到Issue Tracker所發出的E-Mail通知後直接按Reply給發信者這個動作可以說是相當自然與方便, 但這個動作卻是團隊合作與知識管理的最大殺手, 因為你所reply的e-mail永遠只存在你的信箱和收信人的信箱, 而這些專案進行中的訊息可以說是相當寶貴, 因為 Traking的意義在於走過就必須留下痕跡, 這也為何當我在推導Issue Tracking所一再強調千萬不要使用reply mail的方式寫comment的原因, 但是使用者的習慣還是改不過來..... 不過這一切即將改觀, CodeBeamer 5.0.x 針對這個使用者難以改變的習慣做了一個E-Mail polling的功能, 使用者可以直接回Issue Tracker所發出的訊息, 而這個直接回覆的訊息會routing到codebeamer最後變成所回覆Issue的comment. 以後導Issue Tracking不用再強調不能直接reply e-mail了, 詳細設定請看 http://cb.esast.com/cb/wiki/7119

打開終端機 執行 sudo vi /etc/paths --> 需輸入你的密碼 將要加入的路徑存入/etc/paths後存檔 Logout 再 Login , PATH就生效了.

從我的Blog流量分析中, 竟有為數不少是透過"日文單字"與"日文單字下載"等關鍵字找到我的Blog, 原來我有寫我一篇Howto如何利用Anki這個軟體來背日文單字, 最近幾次考試, 臨時利用Anki抱佛腳, 覺得利用Flash卡的方式, 真的比較容易將單字記下來, 最近學會了日文輸入法, 所以開始將我的日文學習筆記慢慢整理出來, 獨樂樂, 不如眾樂樂,為了發揮維基精神, 我利用Google Sites建立一個Wiki網站, 並將我的Anki日文單字檔案放到這個Wiki , 內容還不是很多, 如果您看過也想一起來寫您的日文學習筆記,或是我寫的有不對的地方您想要修改, 歡迎將您的google e-mail寄到我的google e-mail信箱maoyang.chien at gmail.com, 我可以寄邀請函給您, 大家一起來共筆與學習日文, 我的日文學習wiki網站在 http://sites.google.com/site/japaneselearningnote/ PS. 使用Google Sites後覺得不太像Wiki, 只能說是一個所見及所得的共同編輯HTML Web編輯器. 不過使用上算是相當直覺.

CodeBeamer 5.0開始支援個人起始頁面的客制化功能, 上面這個畫面就是我的CodeBeamer起始頁面的screen shot, 日曆嵌入到我的起始頁面讓個人資訊管理更集中了, 詳細設定請參考 這裏

如果沒有iPhone的Mac User, 你可能會發現Address Book中的偏好設定是沒有與Google同步這個選項, 以下的方法可以將這個功能打開 使用終端機 cd ~/Library/Preferences --> 切換到~/Library/Preference目錄 plutil -convert xml1 com.apple.iPod.plist --> 轉換前可先backup這個檔案 使用文字編輯器或是vi編輯 com.apple.iPod.plist 將<key>Family ID</key> 下面那一行的 <Integer>xxx</Integer>中xxx的值改成10001後儲存 再執行 plutil -convert binary1 com.apple.iPod.plist 打開通訊錄的偏好設定, 就可以看到與Google同步選項了,設定好Google帳號與密碼後. 在執行iSync. (原本以為設好後, Google的聯絡人資料就可以同步到通訊錄, 但是同步動作必須靠iSync來執行). 使用iSync Sync時就會將GMail中的account同步到通訊錄 & 手機, iSync在Sync時必須指定手機, 但是如果沒有手機怎麼辦?有一個變通的方法, 到通訊錄中的偏好設定將與Yahoo同步勾起來,並設定Yahoo帳號登入ID與密碼 這樣執行iSync的Sync時就不一定要有Mobile Phone了 參考 http://www.zaphu.com/2008/05/29/how-to-enable-mac-address-book-syncing-with-googles-gmail-contacts-without-an-iphone-or-mac/

剛才看了這篇文章 蘋果CEO史蒂夫·喬布斯:我如何工作 , 這裡面讓我最激賞的應該是Steve Job對簡單的執著, 對使用者體驗(User experience)的偏執狂. 無論是產品設計, 或是軟體設計都是如此, 我想Steve Job是如何培養他對User Experience的直覺? 對於時尚的美覺? 他何以篤定他喜歡的就是市場所喜歡的? 這篇文章沒有講, 但是在最後提到, Steve Job不是擁有高學歷, 也不是軟體工程專家, 他總是以消費者的角度來看所有的設計, 我想對於產品設計者, 工程師就是一種挑戰, 專業人員最大的包袱就是"專業" , Steve Job沒有包袱, 因為他什麼都不是, 不是MBA, 也不是設計師, 工程師, 他只是個消費者. 所以學習當個 "電腦白痴"也不錯, 也許跳脫"專業" , 會想出更令人親近的產品. 後記: 在寫這篇Blog時, 我發現我已經習慣用Mac了, 很少開Windows了與使用MS-Office, OutLook了 :-), 以往Mac只是當做接Case寫程式工具, 很少去注意Mac的其他功能,但是看了這一篇文章後, 我可更要好好研究Mac的設計哲學, 這裡面可藏有Steve Job的成功思維的祕密.

在日文中有所謂的 傳言文 , 說話者將第三者的信息經過自己判斷後傳給對方, 中文用法為 " 據說.." or "聽說.... ", 予想文 用在看到某個事物的感覺, 例如看到商店中的蛋糕, 然後對身邊的朋友說看起來好像很好吃. 這兩個用法在日文中很容易混淆,所以將這兩個用法整理一下 1. 傳言文 基本形 + そうです 例句 日本の冬は寒い そうです 　聽說日本的冬天很冷 要注意的是　基本形包含名詞,動詞,形容詞, 還包含過去式(ToDo : notes for 基本型's 過去式與現在式 ) 2. 予想文 予想文要注意的是只有現在式沒有過去式 い形容詞: 去い加そうです 　, 否定 去い加くなさそうです 例句 美味し そうです 看起來很好吃 美味し くなさそうです 看起來不好吃 いい(好)的用法為特例要注意! よさそうです よくなさそうです な形容詞: な形容詞語幹+そうです 　 否定為 な形容詞語幹+じゃなさそうです/ではなさそうです 例句 便利 そうです 便利 じゃなさそうです/ではなさそうです 動詞 動詞ます形+そうです 雨が降り そうです　 好像要下雨

StudiVZ涉嫌仿Facebook而面臨倒閉 昨天在電子時報看到這則新聞, 裡面有提到一些Web 2.0智慧財產的衍伸議題, 想要開發Web 2.0應用, 看起來也要小心是否會採到侵權的紅線, 不過心中還是有許多疑問, Web 2.0 idea是否也可以申請專利, 比如說 funp.com , 裡面有許多idea是從國外的 delicious 網站衍生而來, 但是還沒聽說delicious對許多書籤分享網站提告, 但是此文中有提到使用Google or Yahoo混搭服務最好也要仔細看一下API授權條款, Developer往往懶得看使用者授權條款就直接使用了這些混搭服務API, 許多API的條款是有提到不保證資料的永存性的, 如果End User使用了你所提供的Web 2.0服務, 但是卻造成資料遺失或是外洩, 但其原因是由所使用第三方的混搭服務API所造成, 使用者是要控告你? 還是混搭服務的提供者? 這篇新聞沒有講太多, 不過卻引起我心中許多的問號! 看起來要使用別人所提供的服務, 法律相關問題還是要先搞清楚, 尤其是Google的API服務. 這裡有一則 侵權敗訴 YouTube須交用戶資料 新聞, 如果Google敗訴了, 使用YouTube API開發的混搭服務是否會受波及?

日文的 "一定要做某某事" 的標準用法有兩種 書く否定型為 書けない, 所以 一定要寫 的 標準用法 為 書かなければなりません 　 書かなくてはいけません 口語用法 書かなきゃなりません 書かなくちゃいけません 可參考 http://www.thejapanesepage.com/node/832

如果等不及Google App Engine支援PHP的developer可以考慮使用 Aptana (他 有一個Web IDE產品很有名 )所推出的雲端運算服務,下一個支援將會是 Ruby on Rails , 看起來雲端運算未來幾年必會是兵家必爭之地,無論是Web開發軟體工具廠商, 或是提供Web Hosting的ISP真的要小心了.

Google App Engine 發佈的時候,只有Support Python, 最近這幾天Study的結果, 覺得還好, 原來Web Application的Web GUI前端還是可以使用 GWT , 與Server端的溝通在使用RPC, 所以Server side的handler還是必須使用Python, 看起來學Python還是免不了, 不過這樣已經算不錯了, 讓python專心做跟App engine相關的事就好, GUI就交給GWT就好了, 以下是幾個相關連結 Using GWT with Google App engine Python-GWT-RPC

昨天回家時, 剛好遇到樓下鄰居, 寒暄了幾句, 在電梯時他告訴我有件事非我幫忙不可, 他在某家IC Design house上班, 我大概也猜的出來, 他希望我可以幫忙他們產品在Mac產品上的支援, 於是到他家坐了一下, 聽看看最近有什麼新的產品需要Mac support , 我這位鄰居的工作其實蠻好玩的, 在設計一些創新的電子玩具相關產品, 細節我就不多說了, 原來最近Mac在美國真的很熱門, 連消費電子玩具產品都要可以connect Mac電腦, 不過我還是婉拒了他的邀請, 因為我自己在經營公司, 公司也有自己的roadmap在走, 雖然我對電子玩具相當感興趣, 如果早幾年找我, 這種案子我是一定會接的:-), 雖然沒有答應接他們的案子, 不過還是聊的相當愉快, 我也相當樂於跟於我那位鄰居分享一下一些新的想法, 我建議他, 這樣的玩具跟Web 2.0結合其實是有相當的賣點, 如果可以跟FaceBook結合那麼潛力更是驚人, 我那位鄰居馬上接著說, 其實這樣的idea早在兩年前, 他就已經跟老闆上過proposal, 並做了一個prototype, 但是確得不到老闆與客戶的青睞, 接著他拿出手機demo了他當時所做的prototype, 我當場跟他說這個idea相當棒, 我也搞不懂為什麼客戶與老闆為何不願意進行這樣的產品開發與銷售, 他很無奈的說, 終端客戶看不到網路的潛力也影響到老闆對於新創產品的信心. 於是我跟他談到了維基經濟學, 何不用群體的力量來讓這個新創產品合理化? 於是我問他, 你的idea除了老闆知道, 還有那些人知道? 確切說是多少人知道? 他說Sales都知道, Marketing的人也知道, 但是其他人呢? 我的意思是工程師,助理小姐, 甚至是所有公司的人, 讓所有公司的人來討論這個idea, 搞不好會有更多新的想法, 我鼓勵他們使用Wiki與Forum , 從參與討論與idea的修正, 都可以看出這個idea是否有辦法成為明星產品的潛力, 甚至將這個Wiki網站開放給客戶, 讓客戶了解整個idea的輪廓與後續發展潛力, Marketing的人也可以透過線上意見調查來讓終端使用者評論是否會喜歡這樣的產品. 鄰居搖搖頭,他告訴我老闆根本搞不懂維基經濟學, 更不用說Web 2.0到底在搞什麼東東, 我跟他說了Cisco的案例, 他說這也是Cisco

一篇關於研發記錄簿的想法 , 讓我想起多年前進入一家做衛星接收器的一家公司的工作經驗, 我進入的第一天, 人事主管就給我一本研發記錄簿, 並跟我說明老闆每週都會抽檢, 而且離職的時候要交還歸檔, 在我離職的時候, 裡面確實記錄不少我所開發的軟體所遇到的問題與解法, 甚至還包含一個Windows Device Driver的原理與如何編譯的筆記, 過沒多久, 遇到以前的同事, 他告訴我, 公司的一些Device Driver後來改外包了, 因為後面的人還是接不起來, 我突然想起那本研發記錄簿, 裡面我可是很忠實的記錄Driver的開發流程, 怎麼會接不起來? 但是我很懷疑公司是如何處置我的研發記錄, 是不是鎖到某個櫃子永不見天日了? 寫到這裏, 又想到另一個親身經驗, 前年突然接到一通電話, 問我有沒有興趣接USB Scanner的Driver開發, 一問之下, 原來是以前同公司的老同事, 當年待的那家公司早已改組改做DRAM模組, 但是還有一小組在接Scanner的ODM , 我想起當初那家公司可是有過ISO 9000/9001的公司, 而且公司有一個很大的文管中心, 所有研發記錄, 與Source Code最後都要歸檔到文管中心, 如果有這些資料要開發新的Driver並不難, 所以問題是出在那裡? 人才很多, 我並不認為找不到人做, 如果經驗是有透過某種形式儲存, 要傳承並不難, 知識管理系統雖然有, 但是那些知識卻像一灘死水一樣, 無法重複使用, 例如Source Code有歸檔, 但是確無法Build, 原因出在工程師只將Source Code燒在光碟片交出去, 但是卻沒有記錄要用那個版本的compiler來build ? 或是要再安裝Third party library才能成功Compile, 其實這樣的潛在問題每一家公司都有, 沒有爆出問題, 是因為都有相對的"人"在處理, 但是人員的離職, 交接的不完全, 問題就慢慢出來了. 解決之道? 其實我覺得可以借鏡OpenSource的開發模式, 其實我認為OpenSource 雖然組織很鬆散, 可是卻沒有知識流失, 或是知識斷層的問題, 你會發現OpenSource的團隊分享文化, 其實間接的解決這種問題, 而且OpenSource的成員分散在各地, 於是更能善用Issue