我心目中的未來消費跟這有點像, 但 RFID 有先天的問題, 只要穿上具有特定纖維製成的衣服, 就可以阻隔掉部分信號, 這樣, 只要付出少少的錢, 就可以拿很多的東西走, 所謂賠本身意沒人做, 誰會做這樣的投資啊!!!
尋找其他解決方案囉!!!
2008年11月27日 星期四
2008年11月26日 星期三
2008年11月17日 星期一
軟體加(+)減(-)法
忘記在哪篇討論教改的文章看過華人社會習慣減法，美系國家則習慣於加法計算方式，那篇文章說明了一種生活態度，也因為如此，國人在便利商店常會有買55元東西支付105元讓店員找錢的狀況，店員也習慣性地用減法計算然後找了50元給顧客，這種情況如果換到美系社會，肯定會造成困擾...之類的評論；我很認同那篇文章的部分觀點
小弟認為不論是加法、減法，這反映出來的不僅僅是一種現象，更是一種文化，這代表的是傳承的過程，也帶著點強迫的性質，文化的傳遞過程主要是老一輩怎麼說，我們就怎麼做，偶爾加點懷疑、衝突、創新，但日子久了，也就變成另一種約定成俗了；因為工作的關係，近來腦子裡不斷產生類似的疑問，這種加減法的文化背後代表的本質是？
從現象來看，加法文化下成長的小孩較有自信，相信是他們不斷鼓勵各種成就的原因吧；相對的，減法文化培養的小孩確是認為自己還有許多不足處，還有許多可以努力的空間，課後輔導、補習、明星學校...都因為這樣的文化而蓬勃，從這點看來，似乎加法文化比較好！
但是，加法無限擴張之後，大頭症就來了，認為沒有不可能，甚麼事都能做到(也的確做了很多豐功偉業)，但也造就了信用無限擴張與全球性金融風暴的重大危機；反觀華人社會的發展，因為從小的教育使然，總覺得做的不夠好，所以步步為營，採取的策略總是一步一腳印，站穩腳步才往前邁進，也因為如此，華人社會受到的衝擊相對較輕，深思熟慮的做事方法，也凸顯在危機處理的速度上...
講了這麼多，到底跟軟體有甚麼關係？主要是因為目前軟體工法有兩派爭論，一是CMMI之類的全面論點，認為可以透過 CMMI之類的方法去建立軟體工廠；另一派則是講人文，尊重人本的Agile方法論。這兩派方法論的支持者都能講出對方的優點與困難，也都很有道理，贊成CMMI的一方認為Agile過度簡化...，認同Agile的一方則認覺得CMMI過度要求...。
我認為，Agile 就像加法文化，能獲得多少，是累積上去的，因此有許多發展的可能性；而CMMI也可以類比成減法文化，需要透過很多努力去實踐，以達成組織設定的目標，這兩者的優劣，請各握透過加減法的觀點去分析，或許能有新的見解產生喔 ^_^
無論採取加法或減法，提醒各位【勿忘初衷】，先想想專案需要甚麼？然後才思考要採取何種解決方案吧！
小弟認為不論是加法、減法，這反映出來的不僅僅是一種現象，更是一種文化，這代表的是傳承的過程，也帶著點強迫的性質，文化的傳遞過程主要是老一輩怎麼說，我們就怎麼做，偶爾加點懷疑、衝突、創新，但日子久了，也就變成另一種約定成俗了；因為工作的關係，近來腦子裡不斷產生類似的疑問，這種加減法的文化背後代表的本質是？
從現象來看，加法文化下成長的小孩較有自信，相信是他們不斷鼓勵各種成就的原因吧；相對的，減法文化培養的小孩確是認為自己還有許多不足處，還有許多可以努力的空間，課後輔導、補習、明星學校...都因為這樣的文化而蓬勃，從這點看來，似乎加法文化比較好！
但是，加法無限擴張之後，大頭症就來了，認為沒有不可能，甚麼事都能做到(也的確做了很多豐功偉業)，但也造就了信用無限擴張與全球性金融風暴的重大危機；反觀華人社會的發展，因為從小的教育使然，總覺得做的不夠好，所以步步為營，採取的策略總是一步一腳印，站穩腳步才往前邁進，也因為如此，華人社會受到的衝擊相對較輕，深思熟慮的做事方法，也凸顯在危機處理的速度上...
講了這麼多，到底跟軟體有甚麼關係？主要是因為目前軟體工法有兩派爭論，一是CMMI之類的全面論點，認為可以透過 CMMI之類的方法去建立軟體工廠；另一派則是講人文，尊重人本的Agile方法論。這兩派方法論的支持者都能講出對方的優點與困難，也都很有道理，贊成CMMI的一方認為Agile過度簡化...，認同Agile的一方則認覺得CMMI過度要求...。
我認為，Agile 就像加法文化，能獲得多少，是累積上去的，因此有許多發展的可能性；而CMMI也可以類比成減法文化，需要透過很多努力去實踐，以達成組織設定的目標，這兩者的優劣，請各握透過加減法的觀點去分析，或許能有新的見解產生喔 ^_^
無論採取加法或減法，提醒各位【勿忘初衷】，先想想專案需要甚麼？然後才思考要採取何種解決方案吧！
2008年11月14日 星期五
加解密技術入門
加解密技術(Cryptography)有許多種，仿間也有很多相關的書籍介紹，如果您想了解理論部分，例如：Cryptographic Message Syntax、Public key infrastructure...，請善加利用搜尋引擎
如果您要知道怎樣用 Java 語言去開發相關的程式，這篇簡報將是有用的入門資料，這當中提到的程式包括：
1. 單向加密(不可逆)
2. 對稱式加密(可逆)
3. 非對稱式加密
4. 數位簽章
提醒一：要提醒各位的是，關於安控的議題不僅僅是簡報當中報告的這些，還有：使用者身分驗證、URL 驗證、Access Control List、Data Access Control、Logging、Exception Handling、Security Session...等議題都跟安控有關，市面上許多 AP Server 都有提供相關的 API，也還有許多環節被忽略掉，但還是有許多的安全漏洞，如果你要開發嚴謹的系統，建議你可以從這些面向去思考。 ^_^
提醒二: Session Id 是很嚴重的安全漏洞，尤其現在的 RIA/AJAX 當道，正種情況又更加嚴重了，怎說呢？登入系統前駭客程式可以把 session id 擷取下來，等你登入系統取得授權後，駭客程式便可以使用該 session id 去模擬授權成功後的所有作業，這過程中完全不用知道使用者的帳號 & 密碼...
如果您要知道怎樣用 Java 語言去開發相關的程式，這篇簡報將是有用的入門資料，這當中提到的程式包括：
1. 單向加密(不可逆)
2. 對稱式加密(可逆)
3. 非對稱式加密
4. 數位簽章
提醒一：要提醒各位的是，關於安控的議題不僅僅是簡報當中報告的這些，還有：使用者身分驗證、URL 驗證、Access Control List、Data Access Control、Logging、Exception Handling、Security Session...等議題都跟安控有關，市面上許多 AP Server 都有提供相關的 API，也還有許多環節被忽略掉，但還是有許多的安全漏洞，如果你要開發嚴謹的系統，建議你可以從這些面向去思考。 ^_^
提醒二: Session Id 是很嚴重的安全漏洞，尤其現在的 RIA/AJAX 當道，正種情況又更加嚴重了，怎說呢？登入系統前駭客程式可以把 session id 擷取下來，等你登入系統取得授權後，駭客程式便可以使用該 session id 去模擬授權成功後的所有作業，這過程中完全不用知道使用者的帳號 & 密碼...
2008年11月12日 星期三
ORM 繼承與複合鍵設計
客戶用 hibernate 實做中提出一個關於繼承與複合鍵的問題，題目是這樣的：
1. 父類別是抽象類別，父類別已定義 主鍵 = 序號
2. 有兩個子類別繼承
3. 子類別的 主鍵 = 子類別型態 + 父類別序號
要怎樣用 hibernate 的 ORM 實現這種設計?
以下是我的答覆：首先須了解 ENTITY_TYPE 代表類別型態這件事的定義，我猜測 ParentEntity, Child1Entity, Child2Entity 裡頭有有對應的 entityType 屬性，如果答案是肯定的，我就不會用 <discriminator column="ENTITY_TYPE" type="string" length="10" /> 這樣的設定去識別子類別，我會用以下的 ORM 方式去設計
<discriminator column="CLASS_TYPE" type="string" length="10" />
<property name="entityType" column="ENTITY_TYPE" />
<subclass name="Child1Entity" discriminator-value="Child1">
...
</subclass>
<subclass name="Child1Entity" discriminator-value="Child2">
...
</subclass>
如果ParentEntity, Child1Entity, Child2Entity 裡頭沒有對應的 entityType 屬性，那麼複合鑑的問題又要怎樣處理? 這部分有幾種選項
1. 採用 hibernate 提供的 composite-id 設定方式
2. 由物件負責處理，以 ParentEntity 為例
class ParentEntity {
String serial;
String entityType;
public String getSerial() {
return serial;
}
public String getEntityType() {
return tokenType;
}
public String getEntityId() {
return getEntityType()+getSerial();
}
protected void setEntityId(String eid) {
// do nothing
}
}
其 ORM 可以宣告如下
<id name="entityId" column="ENTITY_ID" length="128"/>
3. 另外寫一個 EntityID 產生程式
不知道各位是否有其他見解? 歡迎加入討論
1. 父類別是抽象類別，父類別已定義 主鍵 = 序號
2. 有兩個子類別繼承
3. 子類別的 主鍵 = 子類別型態 + 父類別序號
要怎樣用 hibernate 的 ORM 實現這種設計?
以下是我的答覆：首先須了解 ENTITY_TYPE 代表類別型態這件事的定義，我猜測 ParentEntity, Child1Entity, Child2Entity 裡頭有有對應的 entityType 屬性，如果答案是肯定的，我就不會用 <discriminator column="ENTITY_TYPE" type="string" length="10" /> 這樣的設定去識別子類別，我會用以下的 ORM 方式去設計
<discriminator column="CLASS_TYPE" type="string" length="10" />
<property name="entityType" column="ENTITY_TYPE" />
<subclass name="Child1Entity" discriminator-value="Child1">
...
</subclass>
<subclass name="Child1Entity" discriminator-value="Child2">
...
</subclass>
如果ParentEntity, Child1Entity, Child2Entity 裡頭沒有對應的 entityType 屬性，那麼複合鑑的問題又要怎樣處理? 這部分有幾種選項
1. 採用 hibernate 提供的 composite-id 設定方式
2. 由物件負責處理，以 ParentEntity 為例
class ParentEntity {
String serial;
String entityType;
public String getSerial() {
return serial;
}
public String getEntityType() {
return tokenType;
}
public String getEntityId() {
return getEntityType()+getSerial();
}
protected void setEntityId(String eid) {
// do nothing
}
}
其 ORM 可以宣告如下
<id name="entityId" column="ENTITY_ID" length="128"/>
3. 另外寫一個 EntityID 產生程式
不知道各位是否有其他見解? 歡迎加入討論
2008年11月11日 星期二
測試方法與案例
單元測試是確保成果的基礎，沒有完成單元測試的軟體只是把風險移轉給使用者，這是一種鴕鳥心態，也是驗證莫非定律的不良示範，凡映出來的結果將是更多的客訴，投入更多資源去除錯，成本增加，驗收困難，工作負荷增加...，這些都是沒有妥善執行測試的現象；反之，如果為了品質而過度測試，這當中的資源浪費又要算在誰的頭上呢？
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
2008年11月5日 星期三
OOAD CASE [會議室預約管理]
物件導向分析設計，這是多大的題目阿，習慣上，大家可能會從物件導向的概論開始談起...最後才會切到實務，從邏輯推演的角度去看，這樣比較有次序，但，卻不能滿足即時的需要，所以，這裡從案例出發，各位在看簡報之前，請先從自己習慣的方式去設計，待初步設計完成後再對照這份簡報吧！以下是CRRS會議室預約的題目：
1. 有 20 間會議室可供預約
1.1. 基本設備不同
1.2. 可容納人數不同
1.3. 可預約時段為 08:30~20:00, 以 15 分鐘為單位
2. 有 8 套投影機可供運用
2.1. 預約會議室成功且會議室沒有安裝投影機, 才能預約
3. 預約時, 須記錄與會人數、會議主題、 時段、預約者姓名、 部門、職稱、聯絡資訊等
4. 會議室皆被預約時, 使用者可要求加入先進先出的排隊名單
5. 取消預約時, 系統會依先進先出通知排隊者
6. 使用者可查詢會議室使用情形
7. 管理者可調閱會議室使用紀錄&報表
提醒 : 看簡報前務必先自行做設計，最好能用程式碼去驗證自己的設計!!!
1. 有 20 間會議室可供預約
1.1. 基本設備不同
1.2. 可容納人數不同
1.3. 可預約時段為 08:30~20:00, 以 15 分鐘為單位
2. 有 8 套投影機可供運用
2.1. 預約會議室成功且會議室沒有安裝投影機, 才能預約
3. 預約時, 須記錄與會人數、會議主題、 時段、預約者姓名、 部門、職稱、聯絡資訊等
4. 會議室皆被預約時, 使用者可要求加入先進先出的排隊名單
5. 取消預約時, 系統會依先進先出通知排隊者
6. 使用者可查詢會議室使用情形
7. 管理者可調閱會議室使用紀錄&報表
提醒 : 看簡報前務必先自行做設計，最好能用程式碼去驗證自己的設計!!!
CMMI or AGILE
最近有很多類似的題目，CMMI 很完備，Agile 很輕量，中間的差異似乎非常大，軟體公司到底要採用哪一種方法?
CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。
Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?
結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?
後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...
太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法
衍生閱讀：
1. 軟體設計思維
2. 建構管理
CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。
Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?
結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?
後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...
太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法
衍生閱讀：
1. 軟體設計思維
2. 建構管理
2008年11月3日 星期一
Spring MVC
Spring IoC & AOP 基本概念與運作原理, 同時介紹 Spring MVC 的簡單用法
後語：最近 Spring 又發行了新版，有興趣的人可以去下載，有趣的是，Spring 似乎不再是輕量級...這種發展，是否合乎 Spring framework 的初衷？這種發展是宿命？你會採用哪種觀點...
後語：最近 Spring 又發行了新版，有興趣的人可以去下載，有趣的是，Spring 似乎不再是輕量級...這種發展，是否合乎 Spring framework 的初衷？這種發展是宿命？你會採用哪種觀點...
訂閱：
文章 (Atom)