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结尾，这样能保证变量不会在中间定义。