1.前幾天和羅老濕聊了聊，有幾點感觸。（1）老濕心態不錯，境界比我高（當初還是挺擔心他想不開的）；（2）老濕就是老濕，當他指出某人管理能力不行時，我真想指著他鼻子罵他：你的觀察力真是太TMD明睿了。（哈哈，拍得有點過）

2.最近想開始看hadoop了，靠，要學的東西實在太多！！今天才知道拓撲英文就是top（不看原文書的惡果）。為啥是top捏，搜索了一把。

3.MM出去玩了，輕松一周。

4.去中關村修了一把本子，被宰了一刀。話說，貌似想買mac air了。

5.公司最近做了很多無聊的事情，極其無聊！       深圳南山區，某大學對面地震了。震中19層。

      說真的，我今天才知道這個消息，對此我很震驚！公司做出了一個錯誤的決定，為此它會接受懲罰！

      很天真，很和諧的我今天還在群里面和他們開著玩笑，如此看來那個玩笑是如此的愚蠢和過分！希望那些朋友們，兄弟們渡過這一關。我在遠方支持著你們。          我曾問我家MM：“如果我做了一件事，大家都反對我，罵我！你可能也覺得不對，你還會支持我嗎？ ”

         她說“就算是再怎么不對，我都會支持你的”

         這一次，我明白了。

          她是數字的忠實用戶，她是不懂什么技術。連QQ彈個QQ寵物都不會關（懶得關？！）她甚至都不知道我在做什么工作。

          那天，她對我說“雖然我覺得有點不妥，但是我還是把數字卸載了”

          第二天，她對我說“小豬，我在校內上說我支持你們，好多人罵我！”

          第三天，她對我說“小豬，我相信你。但是我好擔心你們會被人打敗了！”

          我可愛的MM，我傻傻的MM。

          相信我，我在做一件正確的事情。我不會讓你失望。

           我為你而感動....


     難得.....終于放出來了。

     哥幾個敢怒不敢言，對于x總怨言很大。用吃完晚飯出去散步半小時的方式表達無聲的訴求。

     “我艸，我們這可不就像監獄里的犯人，每天出來放風”

      “有點像”

        走到鼎好，我和某童鞋看到聯想的廣告，說了句“牛B”

        眾人鄙視的說，“艸，你倆真是剛放出來的，現在看個廣告都這么有興趣”

        下周的日子還不如這周，最后說一句。哥這輩子再也不吃“吉野家”了。

 http://coolshell.cn/articles/2606.html
       對我來說，一個好的程序員應該是努力去追求盡可能無錯的高質量的符合需求的代碼實現。 一些人也許認為好的程序員是那些懂得多門編程語言，懂得很牛技術的程序員，是的，這在某些情況下是對的。但歸根到底，無論你用什么樣的技術，什么樣的語言，所有的程序被寫出來，其功能都要符合需求以及盡可能地健壯無錯和高質量。  我們可以想像一下，如果一個能力普通的程序員有足夠多的時間來做測試，那么，其也可以保證他的代碼的質量。所以，有一種觀點這樣認為——要達到質量高的代碼只需要有足夠多的時間來做測試。這對于以結果為導向的商業軟件開發中是可以理解的（我們可以看到那些制汽車的產商在汽車測試上花費的精力和時間就可以明白這一道理）。

但是，很明顯，所有的已經開發出來項目都是在不完美的條件下開發出來的，一般來說，幾乎所有的項目都是在最大化程序員軟件的開發速度。而且，很多情況下，我們似乎對深度測試和壓力測試并不是很關心，所以，我們總是在祈禱并期望那些趕工出來的代碼可以正常工作，尤其是在上線的時候，這種唯心主義的價值觀更為強烈。  其實，開發速度和軟件產品質量并不矛盾。好的程序員并一定是技術強的程序員，而是那些可以在不完美的工作環境下保證軟件質量和工作效率的程序員。下面是是五個程序員可以在這種不完美的情況下做得更好的觀點（它們都和語言和技術沒什么關系，只不過是一種你的工作行為，能夠和所有的行業相通），這五個觀點也許可以讓你成為這樣的好程序員。

• 尋找不同觀點：程序員好像并不喜歡技術上有異見的人，他們特別喜歡爭論各自的技術觀點。但是，他們忽略了不同觀點的價值。任何事情都有好有壞，我們應該學會在不同觀點中學習和平衡。這樣才會更多的了解編程和技術。要經常在做事之前問自己和別人，這么做對不對？做完事后問自己，還可不可以改進？努力去尋找別的不同的觀點或方法。程序員應該經常上網，經常和同事討論不同的實現方法，不同的技術觀點，這樣才能取長補短。然而，在實際工作中，我發現程序員們并不喜歡互相請教，因為請教的人怕別人看不起他，而被請教的人總是先貶低對方的能力，哎……（參看《十個讓你變成糟糕的程序員的行為》），如果有這樣的文化氛圍的話，那也沒有關系。上網吧，網上的人誰也不認識誰，可以盡情地問一些愚蠢的問題。呵呵。總之，一定要明白，如果某些事情只有一個觀點，那么你一定要懷疑一下了，沒有觀點和技術方案的比較，沒有百花齊放的情況，你就無法知道是否還有更好的東西。真正的和諧不是只有一種聲音，真正的和諧而是在不同的觀點聲音下取長補短，百家爭鳴（參看《十條不錯的編程觀點》）。否則，你永遠都不會接受到新的觀點，也就無法進步和成長了。

• 千萬別信自己的代碼: 在任何時候，一定要高度懷疑自己的代碼。很多時候，錯誤總是自己造成的。所以，當出現問題的時候，要學會review代碼中所有的可疑點，千萬別覺得某段代碼很簡單，可以略過。事實證明，很多疏忽大意都是在陰溝里翻的船，都是那些很低級的錯誤。在查錯的過程中，切忌過早下結論，切忌四處亂改（參看《各種流行的編程風格》），停下來，想一想，會是哪兒的代碼有重大嫌疑，然后查看一下代碼，捋一捋程序的邏輯（參看《橡皮鴨程序調試法》），調試并驗證一下程序的邏輯和變量在運行時是否是正確的。很多時候，對于那些難纏的問題，最后解決了總是因為我們開始認真回頭審視所有的代碼。只有對自己的代碼保持著高度的懷疑，這樣我們才會想著如何讓其運行得更好更穩定，也會讓我們在單元測試中下更多的功夫，這樣才能更能在那忙碌的環境中節省時間。相信我，在集成測試中fix bug的成本要比在單元測試Fix bug的成本大得多的多。一個簡單的例子就是memory leak。程序員對自己的程序需要有憂患意識，這樣才會越來越成熟，而自己的能力也會越來越強。

• 思考和放松: 做事前多想一想，這樣做事的時候就不會不顧此失彼，手忙腳亂，一旦事情一亂，你的心情也會更亂，于是，事情也就會更亂。最后，你只得重寫，這種事情太多了。而且，在工作中要學會享受，要學會放松心情，我并不是讓你工作的時候聊QQ，我只是說，有時候，心態過于緊張，壓力過大，你的工作成果反而更不好，從而又反過來造成新一輪的焦慮和緊張。我個人認為，思考和放松是可以完美統一的，思考其實就是一種放松，停下來，休息一下，回頭看看走過的路，喝口水，登個高，看看過去走的對不對？總體是個什么樣？總結一下，然后看看前路怎么樣好走，這會你才會越走越好，越走越快。好的程序員都不是那種埋頭苦干的人，好的程序員總是那些善于總結成敗得失，善于思考，善于調整，善于放松的人（參看《優秀程序員的十個習慣》）。不然，我能看到的情形是，你很快地把事干完，回到家剛坐下來，老板或是客戶就打電話來告訴你你的程序出問題了。總之，深思熟慮，動作會很慢，但是你可以保證你工作成果的質量，反而能讓你更多的節約時間。

• 學習歷史，跟上時代: 如果你是從十年前開始編程的，那么，今天的這門語言或是技術會有很多很多的改進和改善。你以前開發一個功能或函數，今天早已被集成時了語言中，而且做得比你的版本要好得多。以前你需要100行代碼完成的事情，今天只需要1行代碼。這樣的事情在未來還會發生，所以，今天的你一定要學會如何跟上時代。但是，你也不要放棄歷史，我現在看到很多程序員對一些現代的語言和技術使用的非常好，他們可以很容易地跟上時代。但不要忘了，計算機世界的技術更新和技術淘汰也是非常猛的。所以，你一定要學習歷史，這些歷史不是產商的歷史，而是整個計算機文化的歷史（參見《Unix傳奇》）。只有通過歷史，你才能明白歷史上出現的問題，新技術出來的原因，這樣才能夠對今天的這些新的技術更了解，也才能明白明天的方向在哪里。學習歷史和跟上時代都是相當重要的。使用新型的技術，停下來接受培訓，可以讓你工作得更快，更高效（參看《未來五年程序員需要掌握的10項技能》）。而學習和總結歷史，才會讓你在紛亂的世界中找到方向。

• 積極推動測試活動: 只有測試才能證明軟件可以正常工作，只有測試才能保證軟件的質量。無論什么產品，都需要經過或多或少的測試。測試地充分的產品或模塊，你會發現其質量總是那么好，測試的不充的產品，質量總是那么次。德系汽車，日系汽車質量怎么樣，關鍵還是在于怎么去測試的，測試的是否充分。所以，在你開發軟件的過程中，如果你說你的程序寫地好，質量高，那么請你拿出實實在在的測試報告。在整個軟件開發過程中，做為一個好的程序員，你應該積極地在各個環節推動項目組進行測試活動。不要以為技術需求階段和設計階段不需要測試，一樣的，只要你要release什么，release的這個東西都需要進行測試。技術需求怎么做測試？用戶案例就是測試案例。在軟件開發的整個過程中，保證產品質量有時候比實現需求更重要，尤其是那些非常重要甚至人命關天的產品。

上面這些五個觀點都是可能讓你在不完美的工作環境中可以工作得更好，更快，更高效，希望能夠對你有用。另外，也歡迎你留下你的觀點！

（全文完）

       最近，某數字公司搶先出手，與本人所在的某公司在輿論等各個方面積極的互動。殃及了池魚，我等小P民天天加班，無休止加班，封閉式加班。非得弄出個啥東東出來的架勢。一個需要1個月才能弄出來的東西，讓你1個星期搞定。結果可想而知了....

        其實我不是抱怨，我明白公司這么做也沒有辦法；養兵千日用兵一時嘛！可是，我突然發現自己這一年是我這一生有史以來最忙碌的一年了。轉戰了大半個中國，做了兩個產品，得到的回報卻了了。有時不禁反問自己值得不值得。。。哎，罷了！早在知道T3沒通過的那一刻我就已經明白答案。也許回報會在不遠的以后呢？！（god knows！！）

         其實我真不是抱怨，我也明白短時間內工期這么趕怎么可能寫出啥好的代碼。但是我這次是徹底發現自己原來平時寫的代碼是多么的好了。因為我現在看到自己寫出的更垃圾的代碼。本來我以為這輩子再也不可能寫出這么垃圾的代碼來了的。這次終于又讓我證明了一種不可能性。

          其實我真不是抱怨，不就是每天工作12個小時嗎，不就是連續工作20天嘛，不就是吃飯都不離開座位的開發嗎？這真的沒啥，我能挺住！


          其實我只是想等過完這陣忙碌以后，別讓我再維護我那些惡心的代碼，別讓我再用vs2005 debug。讓我能用全屏小寫的字母，在vim里面寫出python風格的cpp，然后輕松一點ac去也....

          這個愿望很簡單不是嗎？ 想遠在深圳的同學致敬，聽說你們也很不容易！           今天在 光合作用 里面待了一下午，非常棒的讀書環境。國慶期間能靜下來讀讀《數據結構》太愜意了。

          感謝MM的建議和耐心陪伴....

          晚上由于太無聊了，上論壇上逛了逛。想想搜索了一把關鍵詞是 XX 密碼框。

          哈哈，看著各種帖子里面大家的討論和神秘高人的爆料，以及某些高手的分析。著實讓我開心了一番，也讓我回想起三年前的種種經歷。

1.某些高手們分析的都差不多已經很徹底了，可能有一些東西還有些誤解，但是內存盜號貌似不成問題。
2.作為一個逆向者有些想法，總是很奇特。但是開發也有開發的無奈，有些事情在不清楚的情況下，說開發能力不行是有點可笑的。
3.想想當年為了對抗某款木馬，想出來的方法。拍著胸脯說三個月內不可能被攻破。哈哈，果然這個算法直到2年后才逐漸浮出水面。
4.看到別人分析出自己的想法，自己不會很生氣，反而會感覺很高興（當然如果說這個算法太爛了，也是會郁悶一下的）。
5.某些同學可能還是要繼續忙了，不過已經與我無關啦。我在這毛都沒有的地方，對他們說：辛苦了！       慶祝一下，去睡覺！

此提一共有三種解法：
1.枚舉
   最樸素的算法，但是一開始我居然不知道如何來枚舉。大概的原理是：以位置1,1開始變化。得到16種位置的最小解法，然后選最少的一個就OK。

2.BFS
   一開始，我想到的就是這個解法。原來還認為是枚舉，但是仔細看看應該是BFS。因為是記錄給自己看的，所以解法不說。

3.直接給結果

   這題和之前的黑白子差不多。不過那題我是BFS過的。所以這題，想看看枚舉人家怎么做的。但是沒想到搜索到了這種解法，對比了一下discuss和他的講解。下面將代碼貼出來。

ps.
1.這個算法居然也用了64ms。
2.一開始用的scanf("%c", &c);忘記了\n,錯了。然后居然牛逼的想到scanf("%c\n", &c);哈哈！
3.鏈接中的作者有部分說錯了，在上面的注釋我更正了一下。
4.不知道為啥poj的域名變成poj.org....
       在用qsort的時候 查了一下msdn，看到include里面是stdlib.h 或者 search.h。然后隨便的用了search.h。沒想到在提交的時候連CE兩次，一開始我還以為我其他的地方語法有問題。在VC6上以.c結尾的形式編譯，應該是能過oj上的編譯器的啊！最后改了兩次，不行了用小號上。終于發現是頭文件的問題。

在VC6上編譯通過但是OJ上CE的案例，總結一下：
1.頭文件：search.h頭文件是c++的庫
2.強制類型轉化:  在C中應該這么寫b = (int)a,而在c++里面可以寫成 b = int(a)
3.new文件時，應該用.c結尾，這樣能保證變量不會在中間定義。