先說說我的背景，打工一族，最近經不起房企的引誘不幸成了傳說中的房奴。打工一族能買得起市區的房子嗎？不能，只能乖乖的到「世外桃源」，開始了漫長的坐車生涯。
職場上我們常說目標導向，任務分解，我想這也同樣適應於約束和監督自己。因為幾次的豪言壯語要在某某日期前攻克某某書籍，但最終目標無法按預期完成，深深體會到制定乙個計畫是必不可少的階段。關於計畫的制定有很多方法，我是採用了scrum的燃盡圖方式。通過燃盡圖我就清楚了解我的進度是提前還是延後，哪些階段效率低，以及在經歷乙個sprint後預估自己的生產量（這裡即是量化的閱讀速度），下個sprint就知道該如何調整。
下圖是乙個真實執行的sprint。我們從第二行開始從左往右來看，左邊backlog填的是書的章節，右邊7.30～8.13代表閱讀日期，以15天作為乙個週期，其他填寫的數字2、1、0代表那個章節還剩餘多少內容沒看完，量化的標準是：2代表完全沒看，1代表看了一半，0代表看完了。在定sprint時，內容多的章節我會考慮再分解，以確保每個章節是1天裡的零散時間能夠看完的。
從上表的執行資料來分析，7月31日那天消滅了序號為03、04的兩個章節，估計是人品爆發了，進度超前；8月1日消滅了05章節，正常進度；8月2日估計偷懶了，執**況跟8月1日持平，即那天沒看任何內容……，一直執行到8月12日，還剩下的章節有06、10、12、13、14，其中12是看了1半。剩餘量較多，最後一天是無法把進度趕上的，因此剩餘的一部分章節需移到下個sprint計畫。
當然，通過燃盡圖的維度就更加直**到每日的執**況。紅點代表理想情況下每日剩餘的閱讀量，藍點即是實際情況，在紅線之下的代表剩餘的閱讀量比預期少，進度提前，否則就是延後。
從上表，我們可以看到7月30日～8月5日期間，基本上就是理想與現實在互鬥，平分秋色，難分難解；到了8月6日以後就杯具了，現實已跟不上理想的腳步，幾乎成了平行線。
思考一下影響上乙個sprint進度的因素是過於樂觀評估過多章節，還是能力侷限、時間有限等不可抗拒因素，以作為判斷是每個backlog適當減少內容量還是維持前面的量化標準的乙個依據。
執行大約兩個sprint以後，自然就能夠更準確地評估何時會看完那本書籍。如果你對每個backlog都能夠做到計畫與實際一致，那麼下一本書的閱讀計畫就可以一次性制定所有的sprint。
必須要有乙個清晰的電子閱讀器，並且最好僅需乙隻手就能夠靈活操作。因為在公交上搖搖晃晃，為了安全需要乙隻手緊握扶手，只有乙隻手能騰出來。這種情況下現實的紙質書籍已經無法勝任，而且一般經典的書籍都較厚，單靠乙隻手無法支撐長期閱讀，除非你想順便健身。說說我個人實踐，剛開始考慮ipad是個不錯選擇，借了一朋友ipad試驗一星期，其重量僅亞於磚頭，介乎於紙質書籍與磚頭之間，ipad mini估計會比較適合，靜待。最終我是選了iphone，更大的原因是我不想出門還額外帶乙個僅用來看書的厚重裝備，輕裝上陣。為什麼我不選專業的電子閱讀器？如亞馬遜的kindle，肯定是看電子書的不二選擇。但對我這種工薪階層來說，單獨購買僅用於看書的裝置，**不合算，說白了還是價值觀問題。
充分利用時間
不知不覺，距離開始接觸安卓這門語言已經時間不短了，從最開始對四大元件都不太了解，到現在已經稀里糊塗的做完了五六個專案。收穫不小，但不是很全，感覺距離真正的開發人員還差一大截。不想再浪費時間，利用這點時間做點實際的事，充實一下自己，由於平時專案中功能比較瑣碎，好多專案都有共同的地方，為了提高開發效率，...
充分利用時間
充分利用時間 你所擁有的最重要的東西就是你的時間，因為你不能創造更多時間。你可以用錢或他人的幫助來節約你的時間，但是，最終你還是會用光自己的時間。所以，你需要對自己如何利用時間瞭如指掌。很多人不知道每件事情花了多少時間，他們有 1000 封未回覆的郵件，卻還說不知道怎麼處理。解決方法就是每天安排的工...
如何才能充分利用SQL索引
背景 目前web的普及太快,很多 都會因為大流量的資料而發生伺服器習慣性宕機,乙個查詢語句只能適用於一定的網路環境.沒有優化的查詢當遇上大資料量時就不適用了.本文主旨 討論什麼情況下能利用上索引.索引 建立索引可以根據查詢業務的不同分為兩種 單一列的索引,聯合索引.顧名思義,單一列索引就是指在表的某...