Tuesday, December 30, 2014

我為什麼想創業

認真回答一下這個問題好了。
認識我比較久的朋友,相信都不會驚訝於我現在要創業這件事。事實上,「創業」一直是我出社會以來的終極目標, 只是當時的心態,跟現在已經大大的不同了。
我 2006 年大學畢業。出社會的第一份工作是在一間大學的計算機中心管全校機房。當時,我每天的生活就是上班 寫寫公司要的程式,下班開開心心的寫部落格。這是一份幾乎等於準公務員的工作,可以研究自己喜歡的技術,下班 寫自己想要寫的文章,每天都很開心。
其他什麼事,我都沒有想,我甚至沒有現在網路上的年輕人這麼野心勃勃,我只想過好自己的日子。
坦白說,我也根本還不知道自己想要當什麼樣的人。我只知道這樣的生活,我還算開心。也許有一天,我會在裡面晉 升上去,變成一個小主管,變成一個大主管,最後可能開始自己公司,最後有一天退休。Anyway,對於細節我並沒 有想像,反正那時候還不是我能考慮到的事。
我在 2007 年接觸了一套技術,叫 Ruby on Rails。這套技術很神奇,能讓你瞬間做好一個網站!
當時的我會寫 PHP,但是並沒有很熟,以我的能力我只有辦法改一些些網站,寫一些表單。 但是比較複雜的大網站,我就作不出來了…加上寫 PHP 真的很燒時間,我有一大堆鬼點子,但是每次用 PHP 寫, 但是搞到最後我都每次都沒有耐心完成。
這對我來說是一個很頭痛的事,所以我一直在找克服這個問題的解法,看是要換語言還是要想辦法改個性。
當時,有前輩跟我說,有套東西很神,寫東西很快,這套東西就是 Ruby on Rails。我也笨笨的,就去買了幾本書, 開始學怎麼寫。其實剛開始也不太會寫,於是又有人跟我說,寫 Rails 就是要用 Mac 才不會卡來卡去。是不是真的我根本 不知道!!但是我當時實在受夠 PHP 了。我想真正學一些厲害的東西。
我當時的月薪只有 35000。一台 Macbook 要大概 36000。我瞞著爸爸媽媽去用永旺分期(六期),買了一台我這輩子買過 最貴的電腦。(那時候我根本窮的要死,一個月拿六千塊去買電腦,加上我平常買書也買很兇,搞到我都快要吃泡麵了。但我 單純的只是下了決心我要學不一樣的技術。)
大概是我很認真的想學吧。我根本不知道 Mac 是不是跟 Rails 有直接關連,但是總之,我照著書認真練技術,下班不寫文章, 就是一直在寫程式。寫著寫著,我竟然有辦法一直亂寫出東西了,而且這東西真的是可以上線的….
真的超爽的。
(待續)
===
更爽的是,我當時無聊亂做的網站( yes..就是 2008 年很紅的 VeryXD),很受歡迎….
哇靠,OK,上班其實很無聊,作自己的網站爽多了,超多人用你的東西。還有一堆人會叫你大大,有創意的大大。 這種生活超爽的,比公務員的日子爽多了。但是寫程式漸漸佔掉我的下班時間,我都沒時間寫部落格了。 加上上班的日子比起下班的日子真是無聊太多倍了。
當時也是什麼創業風潮很紅。
好!既然我現在看起來很厲害!那我要創業!
(其實現在想起來真可怕,我只是不想要那種無聊日子而已,我根本不知道後面是什麼等著我…)
就在這個念頭燃起來沒多久之後,有次去網路上某位大大他家聖誕吃火鍋,我就順口跟他提起,我想創業這件事。 他澆了我一頭冷水:「你這東西開不成公司」。(其實也沒有很狠,也只講了這一句,但他也沒跟我說為什麼。)
我當時聽了很震驚,也很生氣。但是很快的我就冷靜了。因為我不知道我在氣什麼。他也不像看不起我的能力…
看起來應該是我太天真了。我開始研究,我到底哪裡天真?
很快的,大概因為是念數學出身的關係,我很快就分析出我哪裡很天真:
  1. 這東西要賣給誰?
  2. 誰要付錢給我?
  3. 都收不到錢,我辭職要靠什麼吃飯?
  4. 就算都不考慮錢的問題。我自己一個做的完這些網站上的 feature 嗎?
  5. 我就算 Rails 技術很厲害,但這麼多功能,看起來我自己也作不完,那可能我也要請人,請人要花 多少錢?我付的起嗎?
  6. 就算我請的起人,我管的動人嗎?我知道怎樣團隊合作嗎?如果不知道豈不是浪費錢!
  7. 我只有一個人,就算我自己寫程式,要賺錢還要跑業務。我一出去跑業務程式工作就停擺了。那怎麼辦?無論如何我都需要請業務….
  8. 業務的錢要從哪裡來??
  9. 請人到底總共要燒多少錢,開公司到底要燒多少錢?就算給我五百萬,那可以擋多久?
我發現,這些答案!我都不知道!!!
他媽的好像只是不想上班被人管作無聊的事而已…我頓時覺得我真的蠢到爆炸了。
(待續)
===
但是自從做了那個網站,並且無意間變得很受歡迎之後,像點燃了我內心一把火。我對未來有了方向:
「我想要作我喜歡做而且拿手的事。作我認為正確的決定,把每件事都做的很好。不管是公司還是網站,產品必需要是賺錢的。我作些事時必須要很開心。」
我還是想要作自己的網站,但是我很清楚知道:當時那九個問題,我都沒有答案。 這樣出去大概直接三個月就變成炮灰死超慘。
所以要創業的念頭就死掉了。我想我可能還是需要龜在現在這家公司繼續練功,練到有一天我都知道這些答案為止吧…。 那又可能也是以後的事了吧 orz
幾個月之後,因為那個網站還是繼續紅下去。所以社群前輩有另外一個大大又約我吃飯想談合作。 跟這個大大吃飯徹底震撼了我。
Why?
我在大學期間,就是一個每天都粘著鍵盤的阿宅。這位大大的文章和技術討論串我都看過,印象中我「自己覺得」我技術沒有跟他差很遠。 但是跟他聊天以後,我超級錯愕,他的程度讓我連車尾燈都看不見….
我回家以後,又再檢討我到底哪裡作錯了,我不是大學時程度沒有跟他差很多嗎? 為什麼他現在這麼強,強到連車尾燈我都看不見…..
很快的我就得出一個經驗,他有在公司上班實戰,玩過超多東西。但是我沒有…
要是我再躲在公務員的舒適窩裡面,慢慢練功練爽的話,我的程度只會被我自己學習的速度和眼界卡住。這一輩子別想翻身了。
一想到這一點,我就他媽的再也忍受不了了。
跟大大聊完天的那個禮拜五,我就辭職了。這時候我根本沒想好我下一步要怎麼走。我只知道,我再不離開這裡,我就會害死我自己。
我其實不知道我之後要做什麼?但是我唯一知道的是,我對那九個問題,我沒有答案。
也許我真的太菜了,我應該去別人的創業公司上班實戰,找答案。而且這比創業更好,我找答案,別人還會付薪水給我。
(待續)
===
我在一群大大開的創業公司找到了工作,接案寫 Rails。當時大概是我最好的選擇了吧… 在裡面有非常非常多的實戰歷練,在這個過程中,我找到了很多我要的答案,不完美,但有答案。
在這個過程中,我本身自己技術上和眼界上也成長了很多。(在這裡很感謝當年收留我的大大群們)
創業公司生活好像跟我想像中的非常的不一樣,有些地方大家作對了,有些地方好像作錯了,但是我說不出來。 我不確定這是不是我要的…
我想換換環境。
於是我換到了一間被收購的所謂「成功」創業公司上班,想看看所謂「正規軍」是怎麼作戰的? 大概是在前一間公司被狠狠鍛鍊的關係吧。我在這裡算非常游刃有餘,事情都很容易完成。 (前一家公司用 Agile / Rails 操兵,也學了不少專案管理技巧)
太容易完成工作,上班就很容易無聊。我就開始看看同事們在做什麼。
這家公司網站流量非常的大,於是我在這裡學到不少 scaling 技術。但是我發現這裡雖然看起來比上一家 公司,比起前一家公司來說「正規」。但是我覺得,工作效率非常非常的低….(個人意見)
這裡不是反而有很多專業的管理階層嗎?怎麼反而會變成這樣。
於是我開始研究「為什麼?」
我回家買了很多管理書,研究為什麼。找出真正的問題,並且問自己,若我是他們,有辦法能夠做的更好嗎? 每次一看到我覺得很離譜的事情,我就回家研究,把答案找出來,把作法背下來。
我沒有帶過人,但是我想這些東西學起來,我想我有一天應該用得到。
就這樣又過了半年。
公司一個專案失火了。老闆拜託我去收那個爛攤子。這個攤子風險很高,我自己也知道。 但是我想試試看。(反正也沒想人救,大家都閃得遠遠的,老闆也坦言他自己知道炸定了,所以派我去只是 希望我用 Rails 搭個門面,讓最後看起來不要炸太慘…)
任務是在一個月之內,把一個 EC 網站做好上線,手上只有三個剛學會寫一點 Rails 的 RD。我被賦予的目標不強求 把這個人家之前做了半年但進度很低的網站做完上線,只要補洞到可以驗收門用就好。
我賭了下去把這之前學到的所有技巧用在這一仗上。每天沒日沒夜的工作,抓進度,寫程式,測試…etc. 最後我們竟然把這個網站「寫完」上線了(yes..在短短的一個月…我自己都覺得我很瘋狂很屌)
完工的那一天我知道,之前我想追求的那一堆問題中的「一個」,已經解掉大半了….
(待續)
但是我還有八個問題躺在那裡沒有答案。
多數都跟錢有關。而且我還是他媽的不知道怎麼 bootstrap 一個 bussiness。
這時候,我現在的老闆(嬸嬸)問我想不想去他那裡上班。(嬸嬸是他的綽號,因為我老是笑他很小氣,像嬸嬸) 那裡什麼都沒有!但是他想要 build 一個很大的網站。
我答應了,雖然我有些朋友笑我是白癡。因為他們說嬸嬸那裡真的什麼資源都沒有,而且他們也不熟網路,而且嬸嬸 是傳說中這個集團「最精打細算,最節儉,個性最固執,最難搞,最臭臉」的高階主管。我幹嘛好好的從集團最紅的網路公司, 跳到一個網路沙漠去幫一個惡魔賣命,不用三個月我大概就會哭著說要調回來了吧。
我不害怕。因為我知道,我已經解了九個問題中的一個答案了。我最起碼最起碼,有辦法搞起一個團隊,真真正正的把產品做出來。
我很想找到下一個能幫我付探索這八個問題的學費的公司。我更希望從這裡獲得的是:面對什麼都沒有的環境,我要怎麼自己爭到這一切, 並且把一個網站做起來….
嬸嬸要是如傳說中的這麼惡魔那更好,打敗惡魔我以後應該什麼都不會怕了。於是我就去了…
我掛了一個「經理」職銜,名為經理,但其實我底下什麼人都沒有。嬸嬸只多扔了一個所謂「專案經理」來幫我作網站,這個專案經理 會寫一些 PHP,然後我們要作整個事業處所有想要做的網站。
我們當時最大的一個網站叫 T 客邦,Alexa 排名 350。嬸嬸希望四年之內做到 Alexa 50。我說我可以。 (其實我不知道我可不可以,但是我覺得有希望)
當時最慘的是,其實我有很多 head account,但嬸嬸不讓我亂用。最好是我一個人就幹出所有東西。我每天找他吵架,慢慢把資源炒出來。
在這裡做事幾乎沒什麼資源,預算只有一點點。我不以為意,我知道,要是我創業,大概也是這樣的情形。我幸運的是,這邊起碼每個月發的出薪水。 除此之外,信任、資源、機器,都要用戰功換來,燒我的肝換,有時候還要跟嬸嬸用騙的騙來….
我知道這很辛苦,但是我待過創業公司,我知道這邊其實還比創業公司壓力小多了,起碼我每天不用煩惱發薪水的錢從哪裡來。雖然每天事情 多到作不完,爆肝都做不完。
我在這裡,把我所知道的答案和學到的技巧用上了。每一個我沒有遇過的狀況,每一個我傷腦筋的狀況,我都盡力去研究怎樣解決,學習下決斷, 學習作抉擇,學習怎樣賺錢,學習怎樣騙資源,學習怎樣編預算,學習如何把做事流程標準化,學習怎樣訓練培養團隊,學習怎樣讓團隊高效率
大概是糟糕的狀況我在其他公司看多了,這裡遇到相同的狀況,我很快就知道怎樣閃避。另外我也利用這個機會,實踐一些,我認為是正確的 想法,但在之前沒有機會施展的。
很快的,不到四個月,我建立一個連鎖事業的雛形…..網站成績幾乎用跳的
就在這時候,我被傳說中發給我年薪幾百萬的 H 社挖走了。
(待續)
===
年薪雖然沒有八百萬,但是我的 offer leter 上面的薪水數字確是超過 100 萬新台幣…。 這也沒什麼好奇怪的。因為我的職稱是「資深經理」。
我的工作就是去 bootstrap 一個新的 service 。
但是很快的,我發現我不喜歡在這家公司的生活。
雖然目標是 bootstrap 一個新的 bussiness。但實質上,我真正做的東西卻不是落在這個目標上。
我是喜歡作東西做事帶團隊向前衝的人,但我在這裡做的更多是無止盡的會議以及寫 mail,以及…幹拐子搶資源。 雖然大家都很羨慕我這麼年輕就當到了一個別人要努力幾十年的位子。擁有了要奮鬥非常久才能賺到的物質水準以及生活品質。
但我清楚,我不喜歡這種生活。相信我,喜歡做事的人,真的讓他拿到「錢多事少離家近」的工作,大概三個月他就會發瘋的…
更何況,在 H 社上班更令人可怕和討厭的事情不是這些事,而是別人都當你中樂透,當你搖錢樹。開口閉口都是錢和勒索請客,這樣的日子過久了真的很厭煩。
所以我辭職了,回去蓋我當初沒有蓋完的城堡。
我是一個非常信守承諾而且認真的人,答應別人什麼事我都會希望我盡可能的做到。 我答應嬸嬸要做到 alexa 50,我沒有做到就走了,我對他非常愧疚。
於是我再次回去找他,希望能再把這件事完成。
能不能做到 50 我真的不知道。但是不管作不做得到,我想要知道自己的能耐。 我再花了半年多…..
嗯,我兌現了我的承諾。
雖然沒有人曾經看好過我,一秒鐘都沒有。每個人都說我說大話,每個人都說我愛吹牛,但是無論如何我作到了。 因為我很清楚我的目標是做什麼。我知道怎麼作。我知道離目標還差多遠。我知道去哪裡找到答案。我知道怎樣在公司能承受的風險內,既當創業家又當專業經理人。 即便有時候我不是那麼 100% 肯定我在做什麼。
我也知道我在這裡是為了什麼,因為我從來沒有放棄我想做的事情。我只是盡力把我能做的事情做的很好。 把事情做的很好,在事業上就很容易被人提拔,很容易順便得到你想得到的一切。( 包括薪水,職位,能夠參與的計畫,知名度 ..etc.)
放棄高階經理人職位,放棄高年薪,可惜嗎?我不覺得。
我不是用虛假的話術騙來這一切,這都是用我逐漸累積出來的想法和實力賺的。我不覺得創造出這些東西而學到的的這一切技能和知識,會隨著我辭職就會蒸發。
我在 2010 年 4 月加入 T 客邦,兩年後我實踐了我的承諾。在這個過程中,我也順便找到當初回答不了的九個問題的答案。
但我很清楚知道,這個事業始終不是我自己的。所以我把這個事業交還給了嬸嬸。
而我要去再作那個我 2008 年做的那一個愚蠢的夢。起碼現在,我看起來沒那麼愚蠢了。
我的新公司網址是 http://rocodev.com 。我提供專業的網站顧問諮詢服務,歡迎參考。

Tips and Tricks: Ignoring library code while debugging in Chrome

Firefox has recently released a feature they call "Black Boxing". It's very useful, you can black-box JavaScript source files on a case-by-case basis. When a library is black-boxed the Debugger ignores it. When you're stepping through lines the Debugger will automatically step through lines contained in black-boxed sources.
This is great for a number of reasons. One is that libraries such as jQuery, Underscore, and many others define functions that iterate lists and invoke a function.
Let's say we've written a library that "does one thing very well", library.js:
exports.forEach = function(list, callback) {
  for (var i = list.length - 1; i >= 0; i--) {
    callback(list[i]);
  };
};
And we use that in our source, application.js:
require('library.js').forEach([1,2,3], function(item) {
  debugger
  console.log("We got item: " + item);
});
When we get to that debugger and start stepping through execution, we keep stepping through the implementation of forEach as well as our callback.
If you black-box library.js and step through execution you will only pause insideapplication.js, which is great, because we probably don't need to debug library code most of the time.
Bravo Firefox team, excellent feature!

What about Chrome?

But what about your days debugging in the Chrome Web Inspector?
Hold on to your hat, because you CAN do just that if you're willing to jump "hearts first and ankles last" into the swampy mire of Developer Tools Experiements. Currently this works in AT LEAST the Chrome dev channel (31.0.1612.2 dev), Canary, and naturally Chromium.
The first step is to enable the Developer Tools Experiments in about://flags


Navigate to the Experiments tab, note the warning of danger, and toggle framework debugging anyway (if anybody asks you about this when you eventually run for President just say you toggled the switch but never inhaled).

Time for the "Texas two-step" of Web Inspector use:
  1. Close the Inspector.
  2. Open the Inspector again.
(Texas Two-Step? Are we developing a Presidential politics meta-theme?)
Now use the settings again, but this time navigate to the General tab, find the "Sources" section and start adding things to skip.

Deep in the bowels of Web Inspector the value of this text box will be passed to
new RegExp(valueFromTextBox)
So keep in mind you obey regex rules.
As noted in the Chromium issue tracker, a nicer UI is probably coming for this. In the meantime, happy hacking!

Monday, December 29, 2014

十個值得你每天喝一杯檸檬水的理由

十個值得你每天喝一杯檸檬水的理由
 
早上醒來可以來一杯溫熱的檸檬或萊姆水,對於健康有許多意想不到的好處。 
以下即是十個值得你每天喝一杯檸檬水的理由
 
1) 溫熱的檸檬水能幫助淨化及刺激肝臟,在抑制分泌過多膽汁的同時,促使膽汁液化。 
2) 溫熱的檸檬水能夠幫助消化,其原子組成類似於唾液及消化液的鹽酸。 
3) 比起其他食物,檸檬水較能幫助肝臟製造更多酵素。 
4) 檸檬水能自然且輕易地清潔腸道。 
5) 檸檬及萊姆含有豐富的鉀,鉀是與鈉一同促進大腦及神經訊號傳送的重要礦物質。憂鬱症、焦慮、神智不清及健忘經常與鉀血含量不足有關;神經系統也需要鉀才能向心臟穩定傳遞訊號,因此檸檬水對於改善心臟健康也有幫助。 
6) 檸檬水當中也含有豐富而且比例均衡的鈣及鎂。鎂有益心臟健康,而鈣則能預防佝僂症。 
7) 檸檬水能幫助降低血壓。 
8) 檸檬水能夠維持人體的酸堿值,即使在餐前喝下也能有助於提高酸堿值。體內環境愈偏向鹼性,抵抗疾病的能力就愈好。 
9) 幫助排除尿酸。 
10) 幫助減少體內黏液。
 
檸檬水使用的必須是不含氯的純水或泉水,將至少半顆檸檬或萊姆完全擠入溫水中,並且不添加任何甜味劑。飲用時應該在早上空腹的時候,飲用後不要馬上吃早餐;有些人建議在早餐前一個小時飲用,效果最好。 
為了維持效率,也可以在前一晚睡前先將沸水以熱水瓶保溫,隔天再混合存放在室溫下的檸檬或萊姆汁,儘快喝下之後即可在早餐前進行其他例行事務。 
每天一杯溫熱的檸檬汁是便宜又簡單的保健方式,可以幫助你改善及維持健康。不妨試看看吧!

熱的檸檬水救你一輩子

熱的檸檬水救你一輩子
 
***  抗癌的檸檬水要沖滾水喝熱的呢!還要含皮一起沖泡。
***  檸檬(柑橘)是一個用來殺死癌細胞的神奇產品,它比化療強一萬倍。
***  比世界上通常應用在化療方面的化療藥物阿黴素產品好一萬倍,它減慢癌細胞的生長。
但更令人吃驚的是:用檸檬提取物這種類型的治療,只會破壞惡性腫瘤細胞,它不影響健康的細胞。
原來抗癌的檸檬水要沖滾水喝熱的呢!還要含皮一起沖泡。 熱的檸檬水救你
 
檸檬---只殺癌細胞?
2-3薄片檸檬放在杯子/容器裡,並加入熱水將會變成鹼性水,每天飲用,對誰都有好處。熱檸檬水能釋放一種苦澀抗癌物質,這是在醫藥領域有效治療癌症的最新進展!請你仔細閱讀以下文章並自己評判它是否有效。涷檸檬水只有維他命C,就如番茄煮熟的比生的好一樣,因生番茄没有茄紅素。
檸檬(柑橘)是一個用來殺死癌細胞的神奇產品,它比化療強一萬倍。

它的口感是愉快的,而且它並不產生像進行化療一樣的可怕影響。
你可以以不同的方式來吃它:它可以吃漿、果汁飲料、果汁冰糕、點心等等……,它具有諸多優點,但最有趣的是,它對囊腫及腫瘤產生影響。這種植物被證明能夠補救所有類型的癌症

血壓太高時,它可以調節血壓、抗抑鬱、抗應激和神經功能障礙。比世界上通常應用在化療方面的化療藥物阿黴素產品好一萬倍,它減慢癌細胞的生長。
但更令人吃驚的是:用檸檬提取物這種類型的治療,只會破壞惡性腫瘤細胞,它不影響健康的細胞。

檸檬水=血液循環+

有空就自己弄點檸檬水來喝喝,一顆檸檬要加一千西西或二千西西的水,依個人喜好的酸度,自己調配!能不加糖就不要加糖,養生又美容!

檸檬水
■ 檸檬汁的好處:
檸檬具有高度鹹性,被認為是很好的治療所有疾病的藥,止咳、化痰、生津健脾。
且對於人體的血液循環以及鈣質的吸引有相當大的助益,其豐富的維他命C,不但能夠預防癌症、降低膽固醇、食物中毒,消除疲勞,增加免疫力,延緩老化,保持肌膚彈性,並且克服糖尿病、高血壓、貧血、感冒、骨質疏鬆症等等。

■ 強化記憶力:
面對生活上的工作壓力,是否感覺到自己的記憶力愈來愈差?面對學校繁重的課業,總是害跟不上進度?就讓每天一杯檸檬汁解決你的問題吧!
根據美國最新研究報告顯示,維他命C和維他命E的攝取量達到均衡標準,有助於強化記憶力,提高思考反應靈活度,是現代人增強記憶力的飲食參考。研究中顯示,由於血液循環功能的退化,造成腦部血液循環受阻,而妨礙腦部功能的正常運作。
檸檬具有抗氧化功效的水溶性維他命C類的食物,因此一天一杯檸檬汁有助於保持記憶力,且對身體無任何副作用,是日常生活中隨手可得的的健康食品。

■ 改善骨質疏鬆:
檸檬中的檸檬酸能使鈣易深化並能螯合鈣,可大大提高人體對鈣的吸收率,增加人體骨密度,進而預防骨質疏鬆症。缺乏鈣質是導致骨質疏鬆症原因之一,而預防骨質疏鬆症第一步是先從改善飲食生活開始,就是常吃含維他命C豐富的檸檬、柚橘類水果。
基於檸檬對人體的血液循環以及鈣質的吸引,非常有幫助。
此外檸檬汁中的檸檬酸還有抗腸炎菌、沙門氏菌、腸道出血性大腸菌0-157等食物中毒菌效果,能減少人體內疲勞物質乳酸產生。

■ 達到美容效果:
檸檬可說是女性的水果,因它能安胎,故稱「宜母子」。它又能美顏,因其檸檬酸能去斑、防止色素沉著,內服外塗均有效果。檸檬本身就是美容妙品,可以促進胃裡蛋白分解砪的分泌,增加腸胃蠕動,幫助消化吸收。
在國外的美容專家稱其為美容水果,認為檸檬汁可以潔膚美容,防止及消除皮膚色素的沉積(即是去斑),能令肌膚光結細膩。所以,每晚睡前如果用檸檬片擦面部皮膚(要持續),即能改善消除臉部上的油脂污垢和瑕疵,並且可以改善皺紋。用蛋白加檸檬汁來做面膜,可以緊膚及去除黃氣,令人容光煥發。而且原來一星期至少一次用檸檬汁來按摩指甲,有令指甲堅固的效用。

■ 可防經濟艙症:
你是否害怕在長期的時間下搭乘飛機呢?日本科學家發現,檸檬汁有助防止乘搭長途飛機的旅客患上經濟客艙症候群,科學家建議長途旅客宜每隔5小時喝一杯檸檬汁,以幫助促進血液循環。研究人員曾在13名乘搭長途飛機的旅客身上進行實驗,讓他們喝下一大杯檸檬汁,然後再進行試驗,實驗結果發現他們的血液循環比之前加快了19%
研究人員解釋,檸檬汁內的檸檬酸和檸檬多酚,均能有效預防深靜脈栓塞,調整血液循環,減低血凝塊的機會。

■ 料理美食:
檸檬汁不但有以上幾種功能,它能夠去除腥味及食物本身的異味,無論是肉類中的腥味、海鮮腥味、蛋腥味、洋菇中的澀味及洋蔥的味道,只要加入少許檸檬汁,可減少這些味道而增加食物的風味。

■ 檸檬的妙用
在三明治旁放片檸檬,可保持三明治的新鮮。
將檸檬汁滴到蘋果切面上,可防止變色。
家裡的芥末存放太久,不妨加二、三滴檸檬汁,辣味就會增加;如用檸檬片蓋面,可保芥末醬新鮮,不會變硬。
檸檬汁也是高超的清潔劑,能去除頑固的污漬。
白色的襯衫沾上紅茶時,趕快用水或溼布輕輕敲打,若還是不管用,滴上一滴檸檬什就可以馬上去除了。
熨衣服時若不小心留下焦痕,試塗上檸檬汁後曬乾,多能除去焦痕。
清洗衣物時最後一道清水中加入數滴檸檬精油,可使衣物保持清新的檸檬香味。
榨完汁的檸檬皮渣,就此丟棄太可惜了,不妨放置在冰箱裡,可以除臭保鮮,或者浸在浴缸裡,泡個舒服的檸檬澡,美白潔身。知道這些運用技巧後,會發現真是一舉數得,好處多多呢!
把一堆檸檬洗淨榨汁,將原汁放入冰箱的製冰盒結成檸檬冰塊,再倒入密封袋(拉鍊袋)放在冷凍庫,要泡檸檬水時,只需取用數個檸檬冰塊來沖泡即可。乘檸檬盛產時價格便宜,作好放冰箱就常有檸檬汁可用,『檸檬』讓你骨本長青,經常外食的上班族,由於蔬果、維他命C的攝取量較為缺乏,長期下來對身體健康是有害無益,該怎麼補救呢?
專家建議回家後可多喝檸檬汁來補充。
基於檸檬對人體的血液循環以及鈣質的吸引,非常有幫助,況且檸檬價錢又不是很貴,所以還不如多吃這種經濟又實惠的東西,既划算又不傷身。

 http://www.erva.nl/lemon-water.htm

每天喝檸檬水好嗎? 喝檸檬水的5個誤區

因為檸檬水有美容養顏的功效所以很多女性朋友都非常喜歡喝,但喝檸檬水也有些事項需要大家重視起來,檸檬水的功效除了美容養顏外還有什麼?檸檬水如何泡才更好喝?一起來了解一下。 每天喝檸檬水好嗎? 由於檸檬過酸,不適於鮮食,人們往往用檸檬製成飲品飲用來攝取其中的營養。比如用鮮檸檬片或干檸檬片泡水,或者直接將檸檬榨汁。專家指出,檸檬中的維生素C可以使人體內的組織細胞間質保持正常狀態,防止細胞組織變脆,失去抵抗力。所以檸檬能夠一定程度上幫助人們預防感冒、抵抗癌症。正常人可以每天飲用檸檬水,但是為了防止檸檬中的酸類物質傷及胃腸,檸檬水的日攝入量最好控制在1000ml以內。胃酸過多或者胃潰瘍的人群最好不要暢飲檸檬水。 注意喝檸檬水有5個誤區 有關檸檬水1:泡得濃點好? 檸檬泡水一定要淡,一片帶皮檸檬泡一紮水,能倒3~4杯。這樣的檸檬水沒有很濃的酸味,不加糖或蜂蜜即可飲用,這樣所含能量更低。檸檬一定要帶皮,切片一定要薄,因為皮的部分含類黃酮更高,可能比檸檬果肉更值得泡,檸檬精油也主要在皮裏面,薄切則檸檬皮中的香氣成分容易泡出來。檸檬皮,包括其他柑橘皮,都含有一些苦味的類黃酮物質,比如橙皮甙、柚皮甙之類,但它們也都是有益成分。有一點淡淡的苦味,和酸味配合,天熱時喝了之後更有解渴的感覺。 有關檸檬水2:不能用熱水? 有人說檸檬不能用熱水泡,怕維生素C損失。實際上,泡檸檬的水不能太涼,否則香味泡不出來。由於檸檬的酸性較強,維生素C在酸性條件下耐熱性較好,沒有想像中那麼容易損失,泡檸檬片的水溫度高於60度完全沒問題。再說,喝檸檬水也不是僅僅為了那點維生素C。溫度升高的時候,食物的酸味會更濃一些,所以熱檸檬水也會顯得更酸。解決這個問題很簡單,只要把檸檬水稍微晾涼再喝就可以了。 有關檸檬水3:會促進結石? 有人說檸檬水不能和富含鈣的食物一起吃,鈣和檸檬酸會結合成沉澱,甚至在體內生成結石,這可就是謠言了。檸檬酸鈣微溶於水,我查了一下,四水檸檬酸鈣的溶解度是0.02克/100克水,似乎不高,但檸檬酸鈣卻是製作補鈣產品的良好材料,因為它不需要胃酸幫忙就能被人體吸收。實際上,檸檬酸不會像草酸那樣促進腎結石,相反,檸檬酸等有機酸是有利於食物中鈣、鎂、鐵、鋅等多種礦物質吸收的,而研究證明檸檬酸對腎結石的預防也是有利的,甚至已經用於腎結石的治療當中。 有關檸檬水4:胃病不能喝? 有人說胃病患者不能喝檸檬水,因為酸性太強會刺激胃,胃酸過度的更不可用。但實際上用一片檸檬來泡一大瓶水,泡出來的檸檬水味道很淡,根本沒有可樂之類甜飲料那麼酸,也不至於會造成胃潰瘍。又不是喝純檸檬汁(純檸檬汁pH2.5左右,和可樂相當)。由於檸檬酸有利於多種礦物質吸收,西方人喜歡把檸檬汁擠在魚、肉、蛋上,認為能幫助消化。對於消化不良者來說,在檸檬水中加薄薄一片姜,就餐時飲用,對促進消化液分泌會有好處。 有關檸檬水5:白天不能喝? 有人聽說檸檬水能美白,但也有人聽說檸檬是一種“感光食品”,擔心白天喝檸檬水之後皮膚會起斑變黑。但這個說法僅限於網上傳言,尚未看到相關研究證據。甚至還有網上信息說維生素C是感光物質,如果真是這樣,所有水果蔬菜都含維生素C,看來人們白天什麼蔬果都不能吃了——顯然是十分荒謬的。從科學角度來說,食物中的主要光敏物質包括葉綠素、核黃素、血紅素。要說吃了光敏物質就長斑,大概首先紅肉就不能吃了(血紅素多),奶類也不能吃了(核黃素多),綠葉菜和獼猴桃都不能吃(有葉綠素),看來白天只能吃糧食了!

http://hk.aboluowang.com/2014/0124/366997.html#sthash.j194lAxA.dpbs

22個喝檸檬水的好處!

檸檬可說是一種神奇的藥果,對人體健康有很大的益處。檸檬具有強鹼性,被認為是治療疾病的良藥。止咳、化痰、生津健脾,且對於人體的血液循環及鈣質吸收均能起到促進作用。含有豐富的維生素C,不但能預防癌症、食物中毒,還能降低膽固醇,消除疲勞,增加免疫力。
每天早晨空腹一大杯檸檬水,這個方法簡單實用,可以起到排毒、美體的功效,幫助身體排除體內的有害物質,達到清腸養生的目的。檸檬水可以排除體內有害物質、美白、排毒、清腸,又可以解渴且沖淡想吃東西的慾望,不需要特別節食,還有預防感冒的效果呢,但是一定要堅持才有效。
檸檬汁的作用
1、增強腦力:
據醫學報告顯示,由於血液循環功能退化,造成腦部血液循環受阻,妨礙腦部細胞的正常工作,造成記憶力退化。而檸檬含有抗氧化功效的水溶性維生素C,能有效改善血液循環不佳的問題。因此每天食用檸檬有助於強化記憶力、提高思考反應的靈活度。
2、消除疲勞和腳部酸痛:
肌肉酸痛方面,檸檬亦有幫助,只有用一塊檸檬在酸痛部位輕擦,即有舒緩疲勞功效。若腳部酸痛,把一個檸檬搾汁混入一盆熱水,用來浸腳,效果奇佳。
3、增強抵抗力:
它含有的大量維生素C和檸檬酸,可幫助消化,促進造血功能,提高機體抵抗力,加速創傷恢復。
4、防治心血管疾病、降血糖:
檸檬酸與鈣離子結合則成可溶性絡合物,能緩解鈣離子促使血液凝固的作用,可預防和治療高血壓和心肌梗死。檸檬酸有收縮、增固毛細血管,降低通透性,提高凝血功能及血小板數量的作用,可縮短凝血時間和出血時間31%~71%,具有止血作用。
檸檬表皮含有的維生素P,可防止人體血管硬化的發展,對改善高血壓和心肌梗塞症狀緩解病情非常有益。方法很簡單,取1枚檸檬和10枚荸薺放在一起用水煎煮。
青檸檬,可降血壓降膽固醇、改善心血管病。它和柚子一樣,含有一種近似胰島素的成分,能降血糖。
5、殺菌:
檸檬含有煙酸和豐富的有機酸,其味極酸。檸檬酸汁有很強的殺菌作用。實驗顯示,酸度極強的檸檬汁,在15分鐘內可把海生貝殼內所有的細菌殺死。
6、促進消化:
檸檬還能促進胃中蛋白分解酶的分泌,增加胃腸蠕動。日常生活中可代醋使用,製作冷盤涼菜及醃食等。
7、抗炎:
檸檬中所含的橙皮甙和柚皮甙具有抗炎作用。而檸檬果皮中的香葉木甙腹腔注射,對角叉菜膠所致的大鼠足蹠水腫有消炎作用。
8、治療風熱感冒:
檸檬富中的維他命C,具確有抗菌作用、免疫效果、協助骨膠原生成等多種功效,平時亦可多喝熱檸檬水,來保養身體,補充維他命C。感冒時一天喝上500至1000cc,可以減輕流鼻涕,感冒散得也快,尤其是剛感冒時,甚至可因此不藥而癒。除了抗菌及提升免疫力,還有開胃消食、生津止渴及解暑的功效,所以用在風熱或挾暑的感冒較合適。
9、防治腎結石:
檸檬汁中含有大量檸檬酸鹽,其中檸檬酸鉀鹽能夠抑制鈣鹽結晶,從而阻止腎結石形成,甚至已成之結石也可被溶解掉。所以食用檸檬能防治腎結石,使部分慢性腎結石患者的結石減少、變小。
10、祛痰:
更鮮為人知的,是檸檬也能祛痰,且祛痰功效比橙和柑還要強。將檸檬汁加暖水和鹽,飲之可將喉嚨積聚的濃痰順利咳出,十分靈驗。感冒初起時,不妨用檸檬加蜜糖沖水飲,可以紓緩喉痛、減少喉嚨乾涸不適。
11、改善骨質疏鬆:
檸檬中的檸檬酸能使鈣易深化並能整合鈣,可大大提高人體對鈣的吸收率,增加人體骨密度,進而預防骨質疏鬆症。缺乏鈣質是導致骨質疏鬆症原因之一,而預防骨質疏鬆症第一步是先從改善飲食生活開始,就是常吃含維他命C豐富的檸檬、柚橘類水果。基於檸檬對人體的血液循環以及鈣質的吸引,非常有幫助。這可是有實驗證明,在日本曾實驗過,參加試驗的共7人,年齡平均為36~59歲,每日早、中、晚飲檸檬果汁150毫升,連續飲用 3個月後,7人中有6人骨密度上升,此外檸檬汁中的檸檬酸還有抗腸炎菌、沙門氏菌、腸道出血性大腸菌0-157等食物中毒菌效果,能減少人體內疲勞物質乳酸產生。
而在義大利的南部一帶盛產檸檬,當地人做任何料理都會使用檸檬提味,使得那裏的老年人個個身體非常健壯、頭腦清晰,所以改善飲食生活不妨將檸檬擠成汁,放在冰箱,口渴時加點水或紅茶當開水來喝,對身體是好處多多。
12、治療風濕病
檸檬汁對風濕病也有很好的療效。
13、防止壞血病:
檸檬所含的大量維生素C,是防止壞血病的妙藥。18世紀,英國海員中曾經出現因缺乏維生素C而引起的壞血病,先後死亡了大約1萬人。醫藥科研部門經過研究實驗,才發現檸檬中的維生素C能夠治療壞血病,海員只要攝入一定數量的檸檬汁,就不會患壞血病了。從此,英國有關部門規定,海員每天喝1杯檸檬汁,不備足檸檬的船不准啟航。
14、檸檬水是美容佳品:
檸檬本身是一種營養和藥用價值都極高的水果。
檸檬中最主要的營養成分除了糖類以外,還有鈣、磷、鐵及維生素B1、維生素B2、維生素C。
鮮檸檬泡水喝,由於維生素含量極為豐富,因此是美容的佳品,能防止和消除皮膚色素沉著,起到美白的作用。
15、喝檸檬水能減肥:
檸檬水可以解渴且沖淡想吃東西的欲望,因此可有效抑制不當飲食,加上一天做15分鐘的運動,效果會十分顯著。
在家裡自己操作就可以達到減肥的效果,所以被稱為「家庭主婦」式的喝水節食法,十分有效。
16、檸檬水幫你消除便秘:
早上起床後,正是胃部最敏感的時刻,胃部送入食物後,就會引起大腸催便之收縮運動,是催起便意的最好時刻。 含有豐富維他命C的檸檬,正是催促排便的催化劑,早上空腹飲用自製的檸檬水,不但可以解決便秘之苦,還可以排除腎,亦有美白肌膚的作用,愛美的女性朋友不妨一試。
17、平衡pH值:
每天喝檸檬水能減少你身體整體的酸度。
18、幫助消化:
檸檬汁有助於身體代謝。幫助肝臟產生膽汁,並減少胃灼熱及便秘。
19、是一種利尿劑:
檸檬在體內,有助於身體淨化使排尿的速度增加。因此,毒素能以更快的速度釋放排掉。
20、減輕呼吸道問題:
溫檸檬水有助於擺脫胸部感染和阻止煩人的咳嗽。它被認為是有助於哮喘和過敏症的人。
21、幫助精神:
當身體與精神壓力耗盡時,最先消耗維他命C。
22、幫助戒除喝咖啡的習慣。

Painless Software Schedules

Wednesday, March 29, 2000
This article is obsolete.
Over the years, I've learned a lot more about schedules and estimates. A newer, far better method for producing accurate software schedules painlessly is Evidence-Based Scheduling. Read that instead.
This article remains here for archival purposes, but please don't read it!
Last October, the Northeast US was plastered with ads for something called Acela, a new express train running from Boston to Washington. With TV ads, billboards, and posters everywhere, you'd think that it would have created some demand for Amtrak's new express service.
Well, maybe. Amtrak didn't get a chance to find out. Acela was delayed, and delayed again, so the marketing campaign played out while Acela service wasn't even available. Which reminded me of something I heard a marketing manager say when his product got a rave review one month before it went on sale: "Great publicity! Too bad you can't buy the dang thing!"
Testosterone-crazed game companies like to brag on their web sites that the next game will ship "when it's ready". Schedule? We don't need no stinkin' schedule! We're cool game coders! Most companies don't get that luxury. Ask Lotus. When they first shipped 123 version 3.0, it required an 80286 computer, which wasn't very common then. They delayed the product by 16 months while they worked to shoehorn it into the 640K memory limit of the 8086. By the time they were done, Microsoft had a 16 month lead in developing Excel, and, in a great karmic joke, the 8086 was obsolete anyway!
As I write this, Netscape's 5.0 web browser is almost two years late. Partially, this is because they made the suicidal mistake of throwing out all their code and starting over: the same mistake that doomed Ashton-Tate, Lotus, and Apple's MacOS to the recycle-bins of software history. Netscape has seen its browser share go from about 80% to about 20% during this time, all the while it could do nothing to address competitive concerns, because their key software product was disassembled in 1000 pieces on the floor and was in no shape to drive anywhere. That single bad decision, more than anything else, was the nuclear bomb Netscape blew itself up with. (Jamie Zawinski's world-famous tantrum has the details).
So, you have to make a schedule. This is something almost no programmer wants to do. In my experience, the vast majority just try to get away with not making a schedule at all. Of the few that make a schedule, most are only doing it because their boss made them do it, halfheartedly, and nobody actually believes the schedule except for upper management, which simultaneously believes that "no software project is ever on time" and in the existence of UFOs.
So why doesn't anybody make a schedule? Two key reasons. One, it's a real pain. Two, nobody believes that it's worth anything. Why go to all the trouble working on a schedule if it's not going to be right? There is a perception that schedules are consistently wrong, and only get worse as time goes on, so why suffer for naught?
Here's a simple, painless way to make schedules that are actually correct.
1) Use Microsoft Excel. Don't use anything fancy like Microsoft Project. The trouble with Microsoft Project is that it assumes that you want to spend a lot of time worrying about dependencies. A dependency is when you have two tasks, one of which must be completed before the next one can begin. I've found that with software, the dependencies are so obvious that it's just not worth the effort to formally keep track of them.
Another problem with Project is that it assumes that you're going to want to be able to press a little button and "rebalance" the schedule. Inevitably, this means that it's going to rearrange things and reassign things to different people. For software, this just doesn't make sense. Programmers are not interchangeable. It takes seven times longer for John to fix Rita's bug than for Rita to fix Rita's bug. And if you try to put your UI programmer on a WinSock problem, she'll stall and waste a week getting up to speed on WinSock programming. The bottom line is that Project is designed for building office buildings, not software.
2) Keep it Simple. The standard format I use for schedules is so simple you can memorize it. You start with just seven columns:


Feature Task Priority Original Estimate Current Estimate Elapsed Remain
0
0
0

Note: Remain = Current Estimate - Elapsed

If you have several developers, you can either keep a separate sheet for each developer, or you can make a column with the name of the developer working on each task.
3) Each feature should consist of several tasks. A feature is something like adding a spell checker to your program. Adding a spell checker consists of quite a few discrete tasks that the programmer has to do. The most important part of making a schedule is making this list of tasks. Thus the cardinal rule:
4) Only the programmer who is going to write the code can schedule it. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to do the work can figure out what steps they will need to take to implement that feature. And only the programmer can estimate how long each one will take.
5) Pick very fine grained tasks. This is the most important part to making your schedule work. Your tasks should be measured in hours, not days. (When I see a schedule measured in days, or even weeks, I know it's not real). You might think that a schedule with fine grained tasks is merely more precise. Wrong! Very wrong! When you start with a schedule with rough tasks and then break it down into smaller tasks, you will find that you get a different result, not just a more precise one. It is a completely different number. Why does this happen?
When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take. Write subroutine foo. Create dialog such and such. Read the wawa file. These steps are easy to estimate, because you've written subroutines, created dialogs, and read wawa files before.
If you are sloppy, and pick big "chunky" tasks ("implement grammar correction"), then you haven't really thought about what you are going to do. And when you haven't thought about what you're going to do, you just can't know how long it will take.
As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you're not breaking it down enough.
Here's another reason to pick fine grained tasks: it forces you to designthe damn feature. If you have a hand-wavy feature called "Internet Integration" and you schedule 3 weeks for it, you are doomed, buddy. If you have to figure out what subroutines you're going to write, you are forced to pin down the feature. By being forced to plan ahead at this level, you eliminate a lot of the instability in a software project.

6) Keep track of the original and current estimate. When you first add a task to the schedule, estimate how long it's going to take in hours and put that in both the Orig[inal] Est[imate] and Curr[ent] Est[imate] columns. As time goes on, if a task is taking longer (or shorter) than you thought, you can update the Curr Est column as much as you need. This is the best way to learn from your mistakes and teach yourself how to estimate tasks well. Most programmers have no idea how to guess how long things will take. That's okay. As long as you are continuously learning and continuously updating the schedule as you learn, the schedule will work. (You may have to cut features or slip, but the schedule will still be working correctly, in the sense that it will constantly be telling you when you have to cut features or slip). I've found that most programmers become very good schedulers with about one year of experience.
When the task is done, the Curr Est and Elapsed fields will be the same, and the Remain field will recalc to 0.
7) Update the elapsed column every day. You do not really have to watch your stopwatch while you code. Right before you go home, or go to sleep under the desk if you're one of those geeks, pretend you've worked for 8 hours (ha!), figure out which tasks you've worked on, and sprinkle about 8 hours in the elapsed column accordingly. The remaining time field is then calculated automatically by Excel.
At the same time, update the Curr Est column for those tasks to reflect the new reality. Updating your schedule daily should only take about two minutes. That's why this is the Painless Schedule Method -- it's quick and easy.
8) Put in line items for Vacations, Holidays, etc. If your schedule is going to take about a year, each programmer will probably take 10 to 15 days of vacation. You should have a feature in your schedule called vacations, one for holidays, and anything else that consumes people's time. The idea is that the ship date can be calculated by adding up the remaining time column and dividing by 40 -- that's how many weeks of work are left, including everything.
9) Put debugging time into the schedule! Debugging is the hardest to estimate. Think back to the last project you worked on. Chances are, debugging took from 100% - 200% of the time it took to write the code in the first place. This has to be a line item in the schedule, and it will probably be the largest line item.
Here's how it works. Let's say a developer is working on wawa. The Orig Est was 16 hours, but so far it has taken 20 hours and it looks like it needs another 10 hours of work. So the developer enters 30 under Curr Est and 20 under elapsed.
At the end of the milestone, all these "slips" have probably added up to quite a bit. Theoretically, to accommodate these slips, we have to cut features in order to ship on time. Luckily, the first feature we can cut is this great big feature called Buffer which has lots o' hours already allocated for it.
In principle, developers debug code as they write it. A programmer should never, ever work on new code if they could instead be fixing bugs. The bug count must stay as low as possible at all times, for two reasons:
1) It's easier to fix bugs the same day you wrote the code. It can be very hard and time-consuming to fix bugs a month later when you've forgotten exactly how the code works.
2) Fixing bugs is like doing science. It is impossible to estimate when you will make the discovery and solve the bug. If there are only one or two outstanding bugs at any given time, it's easy to estimate when the product will ship, because there's not much un-estimateable science in your future. On the other hand, if there are hundreds or thousands of outstanding bugs, it is impossible to predict when they will all be fixed.
If developers always fix bugs as they go along, what's the point in having a debugging line item? Well, even if you try to fix every bug as you go along, at the end of every milestone, there is inevitably a lot of bug fixing when testers (internal and beta) find the really hard bugs.
10) Put integration time into the schedule. If you have more than one programmer, inevitably, there will be stuff that two programmers do that is inconsistent and needs to be reconciled. They might both implement dialog boxes for similar things that are unnecessarily inconsistent. Somebody will have to go through all the menus, keyboard accelerators, toolbar tools, etc., cleaning up and organizing all the new menu items that everybody has been adding willy-nilly. There will be compiler errors that show up as soon as two people check in code. This has to be fixed, and it should be a line item on the schedule.
11) Put buffer into the schedule. Things tend to run over. There are two important kinds of buffer you might want to consider. First: buffer to account for tasks that took longer than originally estimated. Second: buffer to account for tasks that you didn't know you would have to do, usually because management has decided that implementing wawa is SUPER IMPORTANT and cannot be left out of the next release.
You may be surprised to find that vacations, holidays, debugging, integration, and buffer time add up to more than the actual tasks do. If you're surprised by this, you haven't been programming for long, have you? Ignore these at your peril.
12) Never, ever let managers tell programmers to reduce an estimate. Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I'm behind schedule, I feel doomed and depressed and unmotivated. When I'm working ahead of schedule, I'm cheerful and productive. The schedule is not the place to play psychological games.
If your manager makes you reduce an estimate, here's what to do. Create a new column in the schedule called Rick's Estimate(assuming your name is Rick, of course.) Put your estimate in there. Let your manager do whatever she wants with the Curr Est column. Ignore your manager's estimates. When the project is done, see who was closer to reality. I've found that just threatening to do this works wonders, especially when your manager realizes that they've just gotten into a contest to see how slowly you can work!
Why do inept managers try to get programmers to reduce estimates?
When the project begins, the technical managers go off, meet with the business people, and come up with a list of features which they thinkwould take about 3 months, but would really take 9. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 3n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. Reality sinks in.
Inept managers try to address this by figuring out how to get people to work faster. This is not very realistic. You might be able to hire more people, but they need to get up to speed and will probably be working at 50% efficiency for several months (and dragging down the efficiency of the people who have to mentor them). Anyway, in this market, adding good programmers is going to take 6 months.
You might be able to get 10% more raw code out of people temporarilyat the cost of having them burn out 100% in a year. Not a big gain, and it's a bit like eating your seed corn.
You might be able to get 20% more raw code out of people by begging everybody to work super hard, no matter how tired they get. Boom, debugging time doubles. An idiotic move that backfires in a splendidly karmic way.
But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it.
13) A schedule is like wood blocks. If you have a bunch of wood blocks, and you can't fit them into a box, you have two choices: get a bigger box, or remove some blocks. If you thought you could ship in 6 months, but you have 12 months on the schedule, you are either going to have to delay shipping, or find some features to delete. You just can't shrink the blocks, and if you pretend you can, then you are merely depriving yourself of a useful opportunity to actually see into the future by lying to yourself about what you see there.
And you know, the other great byproduct of keeping schedules like this is that you are forced to delete features. Why is this good? Suppose you have two features: one which is really useful and will make your product really great (example: tables in Netscape 2.0), and another one which is really easy and which the programmers would love to code (example: the BLINK tag), but which serves no useful or marketing purpose.
If you don't make a schedule, the programmers will do the easy/fun feature first. Then they'll run out of time, and you will have no choice but to slip the schedule to do the useful/important feature.
If you do make a schedule, even before you start working, you'll realize that you have to cut something, so you'll cut the easy/fun feature and just do the useful/important feature. By forcing yourself to chose some features to cut, you wind up making a more powerful, better product with a better mix of good features that ships sooner.
I remember working on Excel 5. Our original feature list was huge and would have gone way over schedule. Oh my! we thought. Those are allsuper important features! How can we live without a macro editing wizard?
As it turns out, we had no choice, and we cut what we thought was "to the bone" to make the schedule. Everybody felt unhappy about the cuts. To assuage our feelings, we simply told ourselves that we weren'tcutting the features, we were simply deferring them to Excel 6, since they were less important.
As Excel 5 was nearing completion, I started working on the Excel 6 spec with a colleague, Eric Michelman. We sat down to go through the list of "Excel 6" features that had been cut from the Excel 5 schedule. We were absolutelyshocked to see that the list of cut features was the shoddiest list of features you could imagine. Not one of those features was worth doing. I don't think a single one of them was ever done, even in the next three releases. The process of culling features to fit a schedule was the best thing we could have done. If we hadn't done this, Excel 5 would have taken twice as long and included 50% useless crap features. (I have absolutely no doubt that this is exactly what's happening to Netscape 5/Mozilla: they have no schedule, they have no definitive feature list, nobody was willing to cut any features, and they just never shipped. When they do ship, they'll have lots of poxy features like IRC clients that they just shouldn't have been spending time on.)
Appendix: Things you should know about Excel
One of the reasons that Excel is such a great product for working on software schedules is that the only thing most Excel programmers use Excel for is maintaining their software schedules! (Not many of them are running business what-if scenarios... these are programmers, here!)
Shared Lists Using the File/Shared Lists command allows everyone to open the file at the same time and edit things at the same time. Since your whole team should be updating the schedule constantly, this really helps.
Auto Filter This is a great way to filter the schedule so that, for example, you only see all of the features that are assigned to you. Combined with Auto Sort, you can see all of the features assigned to you in order of priority which is effectively your "to do" list. Cooooool!
Pivot Tables This is a great way to see summaries and crosstabulations. For example, you can make a chart showing the remaining hours for each developer for each priority. Pivot Tables are like sliced bread and chocolate milkshakes. You gotta learn how to use them because they make Excel a million times more powerful.
The WORKDAY Function from Excel's Analysis Toolpak is a great way to get calendar dates out of a Painless Schedule.

http://www.joelonsoftware.com/articles/fog0000000245.html