2009年4月19日 星期日

Gmail backup MX

AntiSpam: Gmail backup MX
Gmail backup MX

剛在一個網頁寄存商的網頁看到一個叫 「電郵SOS」的服務。介紹如下:


電郵伺服器故障引致重要電郵遺失足以令公司損失大生意,要確保電郵傳送萬無一失,就要先防患於未然。UXXXXX 之「電郵SOS」會於現有電郵伺服器遇到問題時,將電郵暫時送到一個後備儲存伺服器裏,待你的伺服器恢復正常後,暫存在UXXXXX 的郵件便會自動派回 你原來的伺服器,保證電郵不會因伺服器的問題而流失。

客戶現只需$10元(每個電郵地址),便可保障貴公司的電郵商貿往來暢通無阻。


很明顯, 這是一個 backup mx 的服務。

有一個免費的 backup mx 方法是可以用:

1. 替你的 domain 申請一個 Google Apps 的 standard edition 戶口。

2. 替每一個 email address 都加一個戶口 (這是最花時間的,有一些 bulk add gapps account 的方法可用,可以上網找找)

3. 在 DNS MX Record 裏,最少的 preference number (eg 0) 仍然指向公司的 email server。

4. Backup MX 的 preference number則填上 Gmail 提供的。


理論上,只要公司的 email server 不 down,它仍然會收取所有入來的電郵。但總有時候某些 emails 會去了 Gmail Apps 戶口。這只需要:

5. 在公司的 email server 寫上一條 fetchmail 的 rule,寫入所有 Gmail Apps 的 pop3戶口,密碼,然後派送有關郵件到適當郵箱。

淺談技術寫作

蔡學鏞【言程序】部落格: 淺談技術寫作
淺談技術寫作

我在「超完美工作」一文中,提到「技術寫作」一詞,有資訊系的學生來信詢問如何進行技術寫作。收到此郵件,我覺得很高興!因為大多數的IT技術人員都不肯碰技術寫作,要他們寫程式沒問題,要他們寫技術文件簡直要他們的命。所以有人想主動學習技術寫作,難能可貴。

在國內,技術寫作一直是被忽略的主題,我認為,即使是在IT技術書籍作家中,具有技術寫作技巧者的比例還是不高。相反地,國外的IT大公司其實相當重視技術寫作,有時候會公布「Technical Writer」的職缺,這就是專職技術寫作的工作。

技術寫作的幾個基本要求是:

1. 很快學會新的技術
2. 能和技術人員溝通,主動挖掘技術重點
3. 具有流暢且精準的文字表達能力

除此之外,根據所寫的技術文件不同,技術寫作的方式也會有差異,例如:「技術白皮書」、「使用手冊」、「參考手冊」、「快速入門」、「自學手冊」…這些文件的寫作手法、範疇、與編排都是不同的。有些時候,技術寫作所生產的文件,不是最終文件,而是做為行銷等部門的素材,進行二次加工。

如果你有心學習技術寫作,我建議你去看相關的書。在http://www.amazon.com/上面搜尋「Technical Writing」,你可以找到許多本書。或許國內出版社應該引進一兩本翻譯成中文。

2009年4月12日 星期日

愛情紀實

由人地Xanga抄出黎...希望當事人唔介意,我覺得佢真係寫得好好,真係好通透

--------------------------------------------------------------------------------

我擁有過好幾段愛情,
曾經愛與被愛,曾經陷入苦戀;
曾經遇過第三者,曾經為報復一腳踏兩船;
曾經跟大自己差不多十年的男人同居;
也曾經,不小心當上第三者。

戀愛經驗愈多,
就把愛情看得愈通透。

如果,
一個人說愛你也愛別人,那是謊話,
他只是享受當萬人迷的感覺;
當你真正愛一個人,
你根本沒可能分心給第三者。

如果,
一個人老是說他很忙,
忙得沒時間見面,一個電話也沒有打給你;
那他一定不夠愛你,
如果一個人真的愛上另一個人,
再忙再累,也一定會願意抽時間給你。

如果,
你因為自己的異性好友有了男/女友而呷醋,
別誤會是愛上對方而不自覺;
說穿了,你只是覺得對方被他的戀人佔去了,
自己的地位沒有從前重要;
妒嫉,不等於是愛。

如果,
你覺得那個人很美,很英俊,很有型,很可愛,性格很好,
就認為自己愛上他,覺得對方是你的the one;
我可以告訴你,
欣賞對方的優點,那頂多算是喜歡而已,
即使你們在一起,也難以持久;
真正的愛,
是連他的缺點也清楚明白並包容。

如果,
你正陷入一段苦戀,對方待你很差,
你總是哭泣,希望對方能夠愛你多一點;
放手吧,信我,你總會找到更好,
因為,從前的我也試過。

如果,
你覺得一個男生很照顧你,
卻一直過了多年,只當你好友也沒跟你表白;
別再告訴別人他喜歡上你了,
因為這多是你自作多情居多。

如果,
你正跟一個人曖昧,
但對方一直沒有踏出第一步;
鼓起勇氣問對方對你的感覺吧!
失敗了也沒甚麼大不了,
最少,不用再浪費時間。

如果,
當初大家因性格不合分手,
別回頭了,
因為同樣的問題只會隔一段時間繼續發生。

如果,
你還不知道甚麼是真正的愛情,
不要緊,試多幾次,
當你遇到時你就會明白了。

當你遇到真正的愛情,
你會無時無刻感恩,
你會自覺跟對方心靈相通,你會欣賞對方各方面的才能,
喜歡他的孩子氣,喜歡你跟他打打鬧鬧;
即使看到對方的缺點,你也會包容,
因為你明白,人誰完美?
能夠遇上了自己心目中的絕配,
就已經是超級幸運了。

如果,你已經遇到了,
記得要好好的珍惜掌心中的幸福。

2009年4月9日 星期四

採用敏捷方法的軟體開發合約該怎麼簽?

{|ihower.idv.tw| blog } | 採用敏捷方法的軟體開發合約該怎麼簽?
一 般在台灣簽軟體開發合約,最常見的就是固定價格、固定規模型的合約(最晚何時要交出符合這些規格的軟體和文件),但是碰到的問題就是兩造雙方都覺得需求定 不清楚,而陷入對立的情形。接案的希望少做、出錢的希望多要一點,所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途 客戶又不斷加規格、需求頻繁變更或是任何意外,往往就就會開始 Delay,一旦專案延遲,第一個犧牲的就是開發品質了,例如省掉測試作業等。變成開發範圍太大 -> 無法如此交貨必須加班 -> 品質降低的惡性循環。

但是要採用敏捷開發,這種合約要怎麼寫啊?敏捷開發不就說專案一開始不需對規格詳細內容做決定嗎?

XP 方法論提出四個互相影響的專案變數:成本、時間、品質、開發範圍。也就是如果定死價格、時間和範圍,品質就會變成可犧牲的變數。XP 派別認為這四個變數,最常、最應該可以變動的就是開發範圍,也就是定好價格、時程和品質,但是要做什麼再談。回到合約上看,也就定期限、定總價但不定規 格,例如 Kent Beck 建議的:『供應商將提供八個程式設計師為顧客服務,並且兩個月的金額是 $1,000,000。規模每兩週協商一次,協商時根據 XP 方法進行』。

但是不定規模對顧客而言最大的擔心,就是他想要知道他花了 $1,000,000 到底可以得到什麼,因此在台灣還很難接受這種合約方式,照 Kent Beck 的說法,只能玩成價格固定、交期不變、規模求個大概。例如我們和多就使用 User Story (註)的方式來定規模,保留與客戶溝通及實作的彈性,又有可以拿來估價的基準。雖然都會將專案時程切到至多三個月(一季)來做最大的估價範圍,不過還是會 有一開始低估規模而造成專案 delay 風險(所以加強專案的估計技巧也是個努力的方向)。

另一種在台灣常見合約的作法,是分成兩次簽約跟報價,第一次簽約預備開發期,目的是要完整討論出需求跟規格,這部份就會先收取一次費用。第二次簽的約才根據詳細規格再報一次總價。不過這種方式基本上就把敏捷開發一開始『規格不確定也無妨』的優點給犧牲掉了。

還有一種簽法就是計時合約(顧問費),花了多少時間就請多少款,但是基本上這跟固定價格、固定規模型的合約還是有一樣的利益矛盾問題:供應商為了多賺點錢,會希望多加人、多加班多報一點時數。客戶則想要在人力、時間盡可能少的情況下,做出盡可能多的功能。

各位接案的前輩們,你們是怎麼做的呢?

註:

User Story(使用者情節)是一段簡單的功能敘述,以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規 格文件(documentation),不如說它代表(represent)客戶需求,因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下:

* 使用者可以在網站上張貼履歷
* 使用者可以搜尋有哪些工作
* 公司可以張貼新工作
* 使用者可以限制誰可以看到他的履歷

參考資料:

* 極致軟體製程 (Kent Beck)
* 規劃極致軟體製程 (Kent Beck)
* Extreme Programming 理論與實務 (Japen eXtreme Programming User’s Group)
* 同人的生活派對 » 合約與需求變更
* User Stories Applied (Cohn)

Hong Kong Post eCert

香港郵政根源證書已加入「微軟根源證書計劃」

香 港郵政的根源證書(包括 "Hongkong Post Root CA" 及 "Hongkong Post Root CA 1")已加入「微軟根源證書計劃」內;使各微軟視窗系統均可信任由香港郵政發出的電子證書。當 Windows XP 或 2003 系統須核實一電子證書(例:網站上的電子證書(伺服器))時,Windows系統會自行檢查香港郵政的根源證書是否已存在於系統內。如根源證書是不存在於 系統內,Windows系統會自行下載香港郵政的根源證書並將之存於瀏覽器內以供核實電子證書之用。使用Windows XP或 2003之前版本Windows 的用戶亦可下載附有香港郵政根源證書的有關系統更新組件。

按此參閱「微軟根源證書計劃」資料(英文版本)

Hongkong Post

Hongkong Post is a government agency and is a recognized CA under the law of Hong Kong Special Administrative Region (HKSAR) of China, and has been issuing digital certificates under the e_Cert brand name to individuals and organizations of HKSAR since January 2000. Hongkong Post CA operations have been outsourced to E-Mice Solutions. This is documented in the CPS and the Management Assertions. The WebTrust audit covers both Hongkong Post and E-Mice CA operations.

Audit: WebTrust, performed by PricewaterhouseCoopers: Audit Report and Management Assertions

Hongkong Post Root CA 1

InclusionMozilla Foundation to arrange for inclusion

This root has only one direct subordinate, Hongkong Post e-Cert CA 1, which is the signer key and is used to issue different types of recognized e-Certs to individuals and organizations.

Link Download/Install
SHA1D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58
Version3
Modulus (key length)2048
Valid From2003-05-15
Valid To2023-05-15
RevocationCRL
TypeOV
DocumentCertificate Practice Statement for e-Certs
Requested Trust Bits
  • Websites
Bugs Authorisation (408949)
CommentsFile NSS bug after the CRL issues have all been resolved.