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戶口,密碼,然後派送有關郵件到適當郵箱。
2009年4月19日 星期日
Gmail backup MX
淺談技術寫作
淺談技術寫作
我在「超完美工作」一文中,提到「技術寫作」一詞,有資訊系的學生來信詢問如何進行技術寫作。收到此郵件,我覺得很高興!因為大多數的IT技術人員都不肯碰技術寫作,要他們寫程式沒問題,要他們寫技術文件簡直要他們的命。所以有人想主動學習技術寫作,難能可貴。
在國內,技術寫作一直是被忽略的主題,我認為,即使是在IT技術書籍作家中,具有技術寫作技巧者的比例還是不高。相反地,國外的IT大公司其實相當重視技術寫作,有時候會公布「Technical Writer」的職缺,這就是專職技術寫作的工作。
技術寫作的幾個基本要求是:
1. 很快學會新的技術
2. 能和技術人員溝通,主動挖掘技術重點
3. 具有流暢且精準的文字表達能力
除此之外,根據所寫的技術文件不同,技術寫作的方式也會有差異,例如:「技術白皮書」、「使用手冊」、「參考手冊」、「快速入門」、「自學手冊」…這些文件的寫作手法、範疇、與編排都是不同的。有些時候,技術寫作所生產的文件,不是最終文件,而是做為行銷等部門的素材,進行二次加工。
如果你有心學習技術寫作,我建議你去看相關的書。在http://www.amazon.com/上面搜尋「Technical Writing」,你可以找到許多本書。或許國內出版社應該引進一兩本翻譯成中文。
2009年4月12日 星期日
愛情紀實
--------------------------------------------------------------------------------
我擁有過好幾段愛情,
曾經愛與被愛,曾經陷入苦戀;
曾經遇過第三者,曾經為報復一腳踏兩船;
曾經跟大自己差不多十年的男人同居;
也曾經,不小心當上第三者。
戀愛經驗愈多,
就把愛情看得愈通透。
如果,
一個人說愛你也愛別人,那是謊話,
他只是享受當萬人迷的感覺;
當你真正愛一個人,
你根本沒可能分心給第三者。
如果,
一個人老是說他很忙,
忙得沒時間見面,一個電話也沒有打給你;
那他一定不夠愛你,
如果一個人真的愛上另一個人,
再忙再累,也一定會願意抽時間給你。
如果,
你因為自己的異性好友有了男/女友而呷醋,
別誤會是愛上對方而不自覺;
說穿了,你只是覺得對方被他的戀人佔去了,
自己的地位沒有從前重要;
妒嫉,不等於是愛。
如果,
你覺得那個人很美,很英俊,很有型,很可愛,性格很好,
就認為自己愛上他,覺得對方是你的the one;
我可以告訴你,
欣賞對方的優點,那頂多算是喜歡而已,
即使你們在一起,也難以持久;
真正的愛,
是連他的缺點也清楚明白並包容。
如果,
你正陷入一段苦戀,對方待你很差,
你總是哭泣,希望對方能夠愛你多一點;
放手吧,信我,你總會找到更好,
因為,從前的我也試過。
如果,
你覺得一個男生很照顧你,
卻一直過了多年,只當你好友也沒跟你表白;
別再告訴別人他喜歡上你了,
因為這多是你自作多情居多。
如果,
你正跟一個人曖昧,
但對方一直沒有踏出第一步;
鼓起勇氣問對方對你的感覺吧!
失敗了也沒甚麼大不了,
最少,不用再浪費時間。
如果,
當初大家因性格不合分手,
別回頭了,
因為同樣的問題只會隔一段時間繼續發生。
如果,
你還不知道甚麼是真正的愛情,
不要緊,試多幾次,
當你遇到時你就會明白了。
當你遇到真正的愛情,
你會無時無刻感恩,
你會自覺跟對方心靈相通,你會欣賞對方各方面的才能,
喜歡他的孩子氣,喜歡你跟他打打鬧鬧;
即使看到對方的缺點,你也會包容,
因為你明白,人誰完美?
能夠遇上了自己心目中的絕配,
就已經是超級幸運了。
如果,你已經遇到了,
記得要好好的珍惜掌心中的幸福。
2009年4月9日 星期四
採用敏捷方法的軟體開發合約該怎麼簽?
一 般在台灣簽軟體開發合約,最常見的就是固定價格、固定規模型的合約(最晚何時要交出符合這些規格的軟體和文件),但是碰到的問題就是兩造雙方都覺得需求定 不清楚,而陷入對立的情形。接案的希望少做、出錢的希望多要一點,所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途 客戶又不斷加規格、需求頻繁變更或是任何意外,往往就就會開始 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 inclusionThis 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 |
SHA1 | D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58 |
Version | 3 |
Modulus (key length) | 2048 |
Valid From | 2003-05-15 |
Valid To | 2023-05-15 |
Revocation | CRL |
Type | OV |
Document | Certificate Practice Statement for e-Certs |
Requested Trust Bits |
|
Bugs | Authorisation (408949) |
Comments | File NSS bug after the CRL issues have all been resolved. |
網路創業:如何挑選適合你的 Hosting Plan?
: 哈哈,換燈管的 CTO 跑去睡覺了... 來看這次的心情可以 post 多少東西...
: 網站還不大的作法 (跑 LAMP-like 的網站),依照成本由低至高有這些:
: * Shared Hosting
: * VPS
: * Cloud Hosting
: * Dedicated Hosting
: * Amazon EC2
: 我每個都把完整的產品、價錢、優缺點都說一次,下面的價錢沒有特別提就是
: 美金。
: ====
: Shared Hosting 一般都在 $10/month 以下,比較好的像是 Media Temple 是
: $20/month。如果你打算用 shared hosting 發展網站的原型,我的建議就是
: Media Temple 的 (gs) Grid-Service。
: 以 Media Temple 來說,優點當然就是價錢便宜,而且穩定性也高。通常網站
: downtime 都是因為自己改錯程式造成的...
: 缺點是彈性很少,你能用的就是 MySQL 與 PHP/Perl 之類的東西。另外在這種
: 環境下學不到系統管理,對網站長大並不是好事。
Agree。對網站長大並不是好事。而且也只適合在剛起步。
有些人對於架站其實一知半解,可能連 LAMP 都不太懂怎樣 setup。
又或者只是想針對某個議題架個論壇,自家小店鋪的簡單購物車。
通常一般比較不錯的 Shared Hosting,都會有著 CPanel 和 one-click install。
對於起步門檻真的很低。只要會 FTP 與簡單的 HTML 修改技巧就可以開站了。
Shared Hosting 也分國內外。一般國內的就:嗯嗯嗯....XD
國外的 MT 是比較好的選擇,不管 down time 和連線速度上都不錯就是了。
不過有些 Shared Hosting,無限頻寬/無限空間 都是噱頭說好玩的。
現實是,你只要用的資源稍微多一點警告信就來了。甚至還有叫你直接關站滾蛋的。
規模多大會叫你滾蛋呢?基本上頻寬和空間比較不會跟你計較。
是 CPU 用太兇或 request 數、檔案數(縮圖圖床)太多,比較會被趕走。
很多 blog 量大了以後(大約 7000-10000 pv/day)會搬走都是這種原因。
但是做小生意或一般小網站,要能達到這種量其實要一段時間。
一年新台幣花費大概是 3000-5000。通常是年繳。
: ====
: VPS 的價錢依照資源而異,我這邊會推薦的是 Linode,因為同樣價錢比起
: Slicehost 多了不少資源可以用。一般的人我會建議用 Linode 720,原因是
: 程式寫的不好時至少可以用錢換資源...
: VPS 的優點在於整個系統都是由你自己管,你可以自己選擇要用 apache 還是
: lighttpd、nginx,另外 mysql 與 php 都可以自己調整。這些經驗對於網站更
: 大時很重要。
: VPS 的缺點... 基本上我想不太出來有什麼大缺點 XDDD 在網站還不大時真的
: 很適合用。
跑 Rails 就不適合。因為加 Ram 規格就要調大 XD。
Rails 單包跑起來就要 30-50 mb,gem / plugin /mongrel 數量一多就 ...XD
不過 Linode 是可以單加買記憶體單加買 space 的。
Linode 比 Slicehost 規格好一點。但是 Linode 的連線速度不是很漂亮 ...。
VPS 跑 LAMP solution 就還蠻適合的。也可以在上面練連你想要的 solution 這樣。
一年花費大概是 8400。VPS 可月繳,低消大概是一個月 20 USD 左右。
: ====
: Cloud Hosting 的確是在這個位置,會比 Dedicated Hosting 便宜,我說的
: Cloud Hosting 是指 Mosso 的 Cloud Sites。這是一種 Shared Hosting 的
: 進化版本,簡單來說就是用很多台機器分給很多個站台用,比起 Shared
: Hosting 一台機器給很多人用好很多。
: 優缺點的部份跟 Shared Hosting 差不多,除了因為是一堆機器,所以「比較
: 不需要擔心」CPU resource 的部份 (照用量收費)。
就是懶人懶得 scale,程式給廠商,只要記得付錢就好的 solution。
看你用多少資源付多少。
: ====
: Dedicated Hosting 是整台實體機器都租給你用,通常會包含某個 quota 的頻
: 寬,你可以在上面跑自己用慣的 OS,像是 Debian。我個人與公司都租用過好
: 幾家,我都列出來:
: http://www.egihosting.com/
: http://www.hostgator.com/
: http://www.layeredtech.com/
: http://www.limestonenetworks.com/
: 這四個是到現在都還有在用的,服務都還算 okay。
: Dedicated Hosting 的優點就是整台機器都是你的,你租到多少資源就全部都
: 是你自己用。同時這也是上面所有所有方案裡,單位成本可以租到最多資源的
: 方法。
: 缺點在於機器通常不會有 RAID,你要自己想辦法保護資料。另外 Dedicated
: Hosting 需要的技術底子也比其他的深很多。
: 值得一提的是,WordPress.com 初期的機器都是用這種方法租用的。
: ====
自己管機器的意思。外國一些 Dedicated Hosting 對台灣連線速度都蠻漂亮的。
用租的省機器成本外,外國的頻寬比起台灣也是便宜的要命。
一些耗頻寬資源兇但是你不想餵豬(使用者)吃人參(國內頻寬)的服務可以看情況
導過去。
起步價一個月大概是一百多塊美金。
: Amazon EC2 其實是一種 VPS 的變型,他以「小時」計費,但我們這邊不提這
: 個部份。就小站台來說,這台機器 24 小時都開著,一個月也只要 $72。由於
: 一般小網站的流量其實很低,他所租到的資源媲美一台 Dedicated Hosting 主
: 機。
: 其實 Amazon EC2 好用的地方不是在成本 (事實上量大時會因為頻寬費用而使
: 得成本上升),而是在與 Amazon S3 的結合,不過這點是後面的事情...
: 主要的缺點是,你需要自己做 image,這點的技術門檻比其他的方案高很多,
: 因為幾乎沒有中文資料。
如果在外國的話,算蠻適合 startup。租 Dedicated Hosting 或買機器,
其實也要成本。
問題是,如果你不是常態性需要用這些機器,而是某些 event 需要用
(比如說已可預知的 TC 報導,或者是某些 conf 或 news 引爆的爆量)
你真的確定你要 租/買 機器下去嗎?
所以通常解法就是做 AMI,有 event 的時候就打開 deploy 上去
不需要的時候就關掉...
還有就是,某些 application 離尖峰時間的用戶數差的很多,用到的機器數也差很多。
這些都是錢啊。所以有人寫好了軟體出來賣,尖峰就一台台幫你打開 ec2 堆上去 ...
離峰一台一台關掉。很省錢 XD
( Facebook 上很多 application 這樣搞)
EC2 也有 99.95% 的 SLA,這點可以讓人比較放心。
但如果你要這樣玩得話。有一定的技術門檻就是了。
1. 你要會管機器
2. 你要能夠做你要用的 AMI
3. 你要想好架構能這樣亂玩
4. 你要做好資料的備份
簡單說,就是要用經驗和你的知識堆。
至於為什麼要用 S3,well 這邊算其他主題的內容,就不在這邊寫了。
ec2 的收費是照小時以及你開的 slice 大小收費。
http://aws.amazon.com/ec2/#pricing
======
我再多寫一個好了,Google App engine。
不過這個東西技術門檻是要你熟 python,熟 django / tt 佳。db 是用 big table。
每個月會有一部份的免費 quota。每日 5million request 以下的站都適合用。
超過另外 charge。
(不過最近大家濫用已經大大縮減免費的 quota 了)
如果你 python 夠熟,用 app engine 其實很適用。
每日 5m PV 的站大概........
一般人一輩子在台灣創業都很難有這量吧。
5m 應該就有台灣 alexa 前 20。
(剛翻了一下,剛出來是 免費 5m request,現在是 1.3m request)
http://code.google.com/intl/zh-TW/appengine/docs/quotas.html#Resources
2009年4月1日 星期三
急救情緒三大忌
朋輩間的情緒分享,是重要支援,請學習聆聽和接納,避免落井下石、誤犯禁忌。人生中,總會遇到不同的生活轉變或危機,當身邊人情緒崩潰時,請小心,避免犯了「急救情緒三大忌」:
第一忌:壓抑情緒‧迴避感受
「唔好喊啦」、「冇事嘅」這些耳熟能詳的回應,但作為當事人,可能會感到不被認可,甚至認為對方只求盡快「擺平」自己的情緒。作為支持者,能平靜溫和地接納,輕輕遞上一張紙巾、一句「喊/講出嚟會舒服啲」已足夠。
第二忌:專家口吻‧引經據典
某女子因男友移情別戀,向好友哭訴,好友以專家口吻說:「早就叫你唔好信佢啦!」面對感情困擾,有些人會將「經典」道理全數搬出,卻忽略了對方個別情況和感受,當事人需要的是平和開放、陪伴找尋方向的聆聽者。
第三忌:質疑爭辯‧從己出發
朋友在工作上「含寃受辱」,有人會輕視事件嚴重性,大喊「我做嗰間都係咁啦!」又或作出「你搞清楚未呀?」等質問。如果你是當事人,不知道會否有「啞子吃黃連」的感覺?嘗試從朋友的角度出發,避免爭辯,用心傾聽,相信比雄辯滔滔更有建設性。