有一段時間，我的狀態一直是「非常討厭大而全」，列舉幾個例子.
這時候就有人問了：那你們事務怎麼做啊，不同資料庫之間怎麼保證一致性啊。
我就說：不同資料庫之間我們不在這裡考慮事務的問題，需要應用去考慮，我們這裡解決的是超大資料量的問題。
曰：acid都不行，那這個方案不行啊～～
acid是小家子氣，單機的時候，我們強調的東西了。在高併發，大資料量，分布式的環境下，我們只能cap，而且還只能做到其中兩點，我們一般會選擇可用性和分割槽，詳細的論證可以參考程立的一篇分享大規模soa系統中的分布式事務處理，哎，要是一致性、可用性、分割槽全部能完美的做到的話，我還待這裡幹嘛呢？
學習物件導向的時候，我們知道「只做一件事情」，在乙個類裡，只做一件事情，在乙個模組裡，只完成乙個功能，同樣，我們設計乙個類庫，或者乙個產品，應該也需要有最核心的乙個價值所在。但是，我們經常在設計乙個系統的時候，會逐漸逐漸的偏離原來的方向，為什麼？每一次新增需求，新增功能的時候都覺得挺合理的啊，為啥過了一段時間再來看整個系統就覺得不是那麼一回事情了呢？我認為是在新增需求的時候，沒有把好關，要新增的東西是我確實需要的麼？還是可有可無的？是必須要有的麼，還是錦上添花的？我總覺得錦上添花的事情不做也罷，還有好多人在雪中等著我們去送炭呢？先做最重要的事情不吧，分清優先順序很重要。
現在有些人在做設計的時候經常想的很美好，很長遠，挺好的，有長遠的規劃是挺好的，但是實際操作起來就不應該大而全的做，應該向敏捷學習，一點一點的做，經常release。
工作中也是，經常是挺好的乙個想法，結果為了求全，結果做的四不象，需要的東西做得不夠好，暫時不需要的東西，做了一點，集中精力做好需要的東西不是挺好的麼？幹嘛要大而全呢？
補充：犯了乙個錯誤，cap的p是partition而不是 persistence，感謝指正。
討厭那種氣味
現在的生活 多了，溫飽問題目前已經實現突破 不過還存在那些 徘徊在溫飽線的人 記得上次閒暇的時候出去旅遊了一次，去了一次 農村 本來打算 去乙個星期，沒想到那天下午到的第二天下午我就 打道回府 了，因為那 裡的生活習慣和水平真的還是和目前的生活水平還是有一點距離 以前朋友或者長輩偶爾說我是乙個沒有吃...
討厭的青蛙
題目很長，直接放鏈結討厭的青蛙 要求出最長的路徑，就要比較所有的路徑長度。對於每一條路徑，因為步長相等，所以只要確定開始兩個被踩的點就可以求出整條路徑了。假設前兩個點為 x1,y1 x2,y2 則步長dx x2 x1,dy y2 y1,需要判斷下面三個條件是否都滿足。之後的每個點 xi,yi x i...
討厭的青蛙
問題描述 在南韓，有一種小的青蛙。每到晚上，這種青蛙會跳越稻田，從而踩踏稻子。農民在早 上看到被踩踏的稻子，希望找到造成最大損害的那只青蛙經過的路徑。每只青蛙總是沿著一 條直線跳越稻田，而且每次跳躍的距離都相同，如圖8 4 所示。稻田裡的稻子組成乙個柵 格，每棵稻子位於乙個格點上，如圖8 5 所示。...