Kenmingの鮮思維

昨晚很早就睡了，到了約凌晨 12:00 多，好像有起來上個廁所然後再回去睡，就在寤寐翻來翻去間，我突然．．．

與一位陌生人一同買了台彩出的刮刮樂彩券。 然後他先搶著跑去拿彩卷，結果中了 NT$2500 元，我還在想真有些倒楣，搶不過。 結果我抽下一張，竟然是中了有 兩千五百萬 大元耶！！ 哇哈哈，我真不敢相信，再三仔細確認無誤，還怕讓那個陌生人知道，心裡不平衡後，給我搶劫。

我當然是高興的不得了，趕緊就要去銀行領獎。 就在排隊的時候，怪事發生了，那張彩券變成了一隻會咬人的超級大蟾蜍，挖勒，我很害怕，而且銀行職員竟然還問我要不要帶回家養? (因為是我中獎的) 開玩笑，2500 萬變成了一隻會咬人的兇惡蟾蜍，已經夠倒楣了，還要拿回家養？ 結果在場有位好像是有學過道術的阿伯，他小心翼翼的制伏住這隻怪蟾蜍，然後說他可以幫我領養。 這當然好，誰要養這怪物啊？

就在我正驚魂未定時，音樂聲響起啦。 喔，是我的手機鬧鈴，叫我起床了。 呼，嚇出一聲冷汗來，還好原來是作夢。

然後啊，中午要到板橋的時候，就在「許家莊」吃完了滷肉飯，結果看到隔壁就是專賣樂透彩的。 想說怎麼那麼巧，難道是天意要我買彩券的？ 我平常可是不買這種可以忽略掉中獎機率的彩券，幾百塊省著還可以當期貨/選擇權 的手續費呢。 好吧，因為有這個怪夢的加持，碰個運氣試試看，就買了兩張威力彩與一張四星彩囉。

結果呢？ 說真的啦，如果我中大獎，現在肯定是不會寫這篇文章的，當然是要保密啊。 所以當然是 "摃龜" 了，最多只中了兩個號碼！

唉，後來想想，變成那隻惡蟾蜍就是告訴我，我沒有這個中大獎的命啦。

所以，等下次要買彩券的話，就是要等到玄天大帝還是諸神大德來託夢給我，並且告訴我是那些號碼，這樣的話我才肯再去買來試試希望啦。

※ 延伸參考：

• 作了一個怪惡夢～

四年多前所購買的： 換裝 Epson Photo R210+自動供墨系統，因為有一陣子沒有列印而導致墨水頭堵塞，我又懶得專程拿去清洗修理，所以乾脆重新買一臺全新、含加裝連續供墨系統的噴墨印表機好了。

在 Y拍作功課，發現到竟然連它的購物網，都有賣連續供墨系統。 但它有什麼 ZF-INK, ICute 之分，實在搞不懂，再則我比較喜歡能直接過去廠商那邊親自購買，如此有問題或爾後的維修問題也比較方便洽詢。 所以我還是從Y拍找了找，發現到這一家：「墨墨無名」，口碑看來挺不錯的，而且因為是在板橋，從我家中和開車過去，很快就可以到了。 所以，上個星期我已經電話先詢問一些問題，今天左右沒事，下午就衝過去了。 對了，在電話中詢問時，說她們也有提供印表機的印字頭清潔，也包含已安裝其它廠商連續供墨系統的，反正確定能清洗到好才收費，價錢約 NT$200~600，所以順便也把我那臺舊的 R210 送去清洗看看了。

Epson 系列印表機的通病，就是只要一陣子沒有列印，就很容易堵塞。 不過電話中那位小姐對她們家的供墨系統很有信心，掛保證說絕對不會墨水頭堵塞的，基本上就是一個月內能列印個幾遍就可以了。 而現在我是打算，每天都要把大盤的線圖列印下來參考研究。 那個「趨勢生命力」的作者羅威說，每天這樣看 K線與均線，連續看了三個月就能有感覺了；若是沒有感覺，那麼他建議儘早離開這個市場才是，呵呵。

繼續閱讀 »

今天下午，要到板橋拿一臺「連續噴墨系統」的 Epson 印表機。 從我家中和要過去板橋時，因為中午尚未用餐，突然想到，前陣子有看到網友推薦，說中和有家挺有名的滷肉飯，叫作「許家莊」。 我查了地址，就在中和市莒光路，沒想到，竟然離我家還相當遠呢，是已經接近板橋地區了。 用了我的 TomTom 導航 GPS，原來我來過附近，當初是我老婆她的表妹就是租在附近而已，當時經常接送她來我家玩。

我是將近約下午 1:00 時開車過去的，呼，店裡面全部坐滿，生意相當好。 還好門口外有個小桌，反正我是很快用完餐就走了，並不需要講究。 我點了一碗大碗的滷肉飯+滷蛋、一盤滷白菜、一碗排骨湯。 送餐的速度非常快，才不到一分鐘，就全送過來了，結果我以為是如排骨金針湯那樣的，原來是排骨酥湯，我可是比較喜歡金針排骨湯說。~

繼續閱讀 »

從某一個應用系統 (或資料庫系統)要把資料轉移到另一個應用系統 (或資料庫系統)，這個轉移的過程稱之為 "Migration" (相對地，若是同一系統的版本更新，則稱之為 Upgrade)。

上一個月，要從原來 b2evolution Blog 系統轉移 (migrate)到 wordpress 系統時，就如同當初我從 MT 轉移到 b2evolution 一樣，官方的系統均有提供 import (載入) 的 script 檔。 只是， MT 轉 b2evolution 時，當時因為資料結構比較單純，所以完全不用作任何修正，透過 import 工具程式一下子就轉好了；但是，這兩三年來， b2evolution 系統相當積極，版本更新極快，而每一次大版本的更新，必然會變動到 DB Schema，這使得 wordpress 所提供可以 import from b2evolution 的 script 檔，不可能不作修改就可以順利完成轉移作業。

wordpress 官方所提供對各大 Blog 系統的 import script 檔在此：Importing Content。 不過，我真的挺懶，想說若能找到無痛地可以從我現在 b2 1.10.3 版本 → wordpress 2.71 的網友加持修改版，那就更省事了。 結果呢，花了大半天的時間，是有找到啦，像這篇： Import From B2evolution(2.4.6) to WordPress (2.7)。 只是，要收費耶！！ 含售後客服要價 50 USD。 其實啊，這價錢是算便宜的啦，當初我擔任某家公司的 Oracle DBA 時，幫企業客戶作轉檔的話，起碼是 10 數倍以上收費起跳的呢。

不過，想想還是乾脆又自己來動手 DIY 好了。 其實轉檔的原理相當簡單，就是把 Source Schema 對應 (mapping) 到 Target Schema 就對了。 b2evolution 有 31 個表格；wordpress 則只有 10 個 (非常欣賞它的結構簡潔)！ 怎麼會差這麼多？ 主因就是前者是被設計來服務多個部落格用戶的，而後者僅設定單一的部落格，所以前者儲存了非常多的統計數據，而這些，其實是不用轉移的。

轉移的核心會是什麼？ 當然就是本文內容了。 本文就是包含 Post 內文 (content)與迴響 (comment)，一篇內文會包含 0 到 多篇迴響，非常典型的 "Master-Detail" 表格結構，一般就是會有兩個表格個別儲存並以 Key (primary-key to foreign key)來關聯了。 所以只要找出含有 "_post" 字串的表格，大部份就是儲存 Post 內文的主表了。 再以此為中心，把一些如類別 (category)、帳號等額外資訊，給一一的加進來即可。

轉檔的寫法百百種，可以利用 stored-procedure、利用 C#/VB.NET、PHP、Perl 等機制來轉寫轉檔程序。 事實上，對資料結構與 SQL 語法精通的真正高手來說，只要寫個 SQL 陳述 (statement)甚至就可以轉移了。 嗯，我那個 partner Ringle 就是精通此道，他對資料庫的掌握度，我仍是沒有看到一個比他更強悍的。 可惜，他可不幫我作這種小事，而他收費可更是不便宜。 所以呢，我還是又繞回來，下載回來 wordpress 官方的 import script 程式，當然是利用 php 撰寫的，再以此作為轉移程式的 "骨架 (skeleton)"，然後慢慢地調整 SQL 陳述，修改表格與欄位、資料型態等。 呵呵，比想像得簡單，我採用漸進調整的方式作業，大概反覆轉移了有四、五次之多，至最終轉到我滿意正確的結果，大約也才耗上半天的時間而已。

繼續閱讀 »

從 b2evolution 轉移到 wordpress 的過程，吃足最大苦頭的不是轉檔 (migrate)，而是版面的 CSS 設計。

這一次我對版面的需求一開始就打算使用三欄式的 Layout 了，原因是我打算提供更多樣化的一些額外附屬資訊，同時現在是流行大螢幕尺寸，1024*768 以上的瀏覽畫面，已經佔絕大部分使用者的比例了。 我的版面構思是右邊兩側為 Sidebar 列，一個稍寬、另一個稍窄 (均可調整寬度)，左側就是內容 (content) 主頁了。 然後 Sidebars 是設成固定寬度 (fixed-width)，而內容區則可以視瀏覽器寬度的大小而變動 (Liquid-layout)。

當然一開始是透過諸多提供 wordpress 佈景主題 (theme)網站來找尋，結果花了一整天的時間，瀏覽了數百個佈景主題，就是找不到我心中所想的，絕大部分的 CSS Layout 均是採用固定式寬度的設計；再則，我似乎有一些 "潔癖"，看到 style.css 編輯得很凌亂，就挺不舒服的。 後來決定了，自己重寫 css layout！ 我甚至不是 copy 自 default 的 css 當成樣板，而是僅把它當成參考，然後逐漸地邊嘗試、邊摸索，一點一滴試到可以接受為止。

事實上，我發現到，如果 sidebar 與 content 都是可變動的比例式或為固定寬度，那麼 layout 就挺好設計的。 但是像我這樣的需求，反而比想像得還要困難。 更重要的是，我其實不太會 CSS，我是在這一次為了達成我理想中的版面，才去瞭解一些基礎觀念。 版面 CSS 的設計，最基本的就是對所謂的 "Box Model" 要能有清楚的理解才行。起碼你總要知道 margin 與 padding 的差異、float 與 position 的浮動調整，以及還要注意的是 IE 與 Firefox 兩者瀏覽器(及其版本) 的支援程度才行。 這裡我強烈推薦 網站製作學習誌 這個網站， 版主在其一篇：CSS 排版觀念—Box Model ，寫得非常清楚，是一篇相當棒的教學文。

仍然又是透過我的好朋友 Google，查詢到了能達成我理想中版面的 CSS 解法，起碼有三種方式可以達成。 我這裡也不想去比較各種方式的優劣與否，大致上就是作個整理，有興趣的網友們可以去行參考。

• CSS 速戰速決 – 談多欄式編排。
• 樂多Blog排版入門。
• Two-Column Liquid Layout。
• The ‘Blog Style’ 3 column Liquid Layout (Pixel-widths)。

反覆嘗試，我是採用了最後這一個，"The ‘Blog Style’ 3 column Liquid Layout (Pixel-widths)" 。 這個版面的 CSS Layout 設計可以說是相當古怪 ( 簡單的說，它利用一個 200% 的 parent 區塊再折成只有右側 100% 來包含 content 區塊。)、也最複雜，但相對也是最具彈性，無論你用 IE or Firefox or 其它各類瀏覽器，無論你怎麼伸縮，版面真的是不會跑掉 (如側邊欄掉下問題)。

不過，我有做了一些調整。 如果三欄式的兩個 Sidebar 是放在同一側，那麼，我就把它視為是一個 "大" 的 Sidebar (parent)，其內在包兩個左右 "小" 的 Sidebar (child)。 如此我是覺得無論這個大的 sidebar 內部怎麼變化，都是它自己的事，所以也可以任意調整內部甚而再加上 "上與下" 的 sidebar 列了。

怎麼實現最好呢？ 就是把 html 與 css 都寫在同一個 html 檔內，然後打開 IE 與 Firefox，同時去測試比較寫出來後的效果。 對了，我強烈建議，一定要安裝 Firefox 的 Plugin: Firebug， 真是太好用了！ 如此要能追蹤除錯，相當地方便。

我這裡也列出我原先所寫得這一個 css layout template 檔案：
繼續閱讀 »

近日有位來自大陸對岸，就讀軟體工程的同學 Email 來信問了我關於需求獲取的問題。 很難得，並不算是問我 How-to 的問題，而我也覺得他問的問題還挺有意思的，所以也把我個人對其的回覆公佈分享出來。

2009/3/24 cnlogn

王克明老師，您好。
　　我是一個初學軟件工程的學生，正學到需求獲取。因為仰慕佛教的無遮大會的問答機制，又無意間撞到濛濛的秘密基地，發現了前輩（有緣分），於是冒昧請教。
　　我知道需求信息來源，獲取方法/技術。那麼什麼是需求獲取策略？
　　我知道需求三個層次分別是業務需求，用戶需求和功能需求（非功能需求）。那麼什麼是客戶需求？什麼是產品需求？
　　為什麼把領域分析和業務建模放在需求獲取階段？此致
敬禮

2009-03-24

Cnlogn 同學您好：

1. 與其說需求獲取的方法/技術 是一種策略(strategy)，倒不如說是一種態度。 什麼態度呢？ 因為知道不可能一次就能很明確地從使用者端得到正確詳細的需求，所以，需求分析師 (Requirement Analyst, RA)不會也不應該一開始就想要得到所謂正確的需求，而會是以漸增、漸進的方式 (Iteration and Incremental)，從一個所謂的功能單位(例如 Use Case)，逐步地從目標框架，往精確度要求。 所以這是一種目標導向的作法，先確立目標，再來往細節調整。
2. 我覺得是不應該去硬背那個什麼三個層次的需求。應該是說，需求會透過多種不同的角度，理解與紀錄各個不同使用者角色的需求。 包括整體性的業務流程面、包括操作員 (Operator)對系統的局部功能要求、包括整體使用者對系統關於穩定、效能、彈性等非功能性的滿意度需求… 等等。 需求的面向 (View)是很多面的，RA 要能擅長透過多種不同的觀點來看待需求面。
3. 我不會硬性定義所謂的領域分析與業務建模是放在需求獲取階段。 關於分析、設計、乃至實做測試等工作，會是快速跑過一整個循環 (Iteration)，再取得回饋 (feedback)來持續修正調整的。 軟體工程把製程 (Process)固定下來的前提是需求穩定不變，問題是，軟體又不同於其它成熟產業領域的關鍵就在於，需求一直持續地變化。

我曾經寫過一篇：「從軟體架構師(Architect)的觀點來看軟體開發流程」，您可參考看看的。

Best Regards.
Kenming.