1.前幾天和羅老濕聊了聊，有幾點感觸。（1）老濕心態(tài)不錯，境界比我高（當(dāng)初還是挺擔(dān)心他想不開的）；（2）老濕就是老濕，當(dāng)他指出某人管理能力不行時，我真想指著他鼻子罵他：你的觀察力真是太TMD明睿了。（哈哈，拍得有點過）
2.最近想開始看hadoop了，靠，要學(xué)的東西實在太多！！今天才知道拓?fù)溆⑽木褪莟op（不看原文書的惡果）。為啥是top捏，搜索了一把。
拓?fù)鋵W(xué)[1]，是近代發(fā)展起來的一個研究連續(xù)性現(xiàn)象的數(shù)學(xué)分支。中文名稱起源于希臘語「Τοπολογ?α」的音譯。Topology原意為地貌，於19世紀(jì)中期由科學(xué)家引入，當(dāng)時主要研究的是出於數(shù)學(xué)分析的需要而產(chǎn)生的一些幾何問題。發(fā)展至今，拓?fù)鋵W(xué)主要研究拓?fù)淇臻g在拓?fù)渥儞Q下的不變性質(zhì)和不變量。3.MM出去玩了，輕松一周。
4.去中關(guān)村修了一把本子，被宰了一刀。話說，貌似想買mac air了。
5.公司最近做了很多無聊的事情，極其無聊！
posted @
2010-12-04 22:06 margin 閱讀(112) |
評論 (2) |
編輯 收藏
深圳南山區(qū)，某大學(xué)對面地震了。震中19層。
說真的，我今天才知道這個消息，對此我很震驚！公司做出了一個錯誤的決定，為此它會接受懲罰！
很天真，很和諧的我今天還在群里面和他們開著玩笑，如此看來那個玩笑是如此的愚蠢和過分！希望那些朋友們，兄弟們渡過這一關(guān)。我在遠(yuǎn)方支持著你們。
posted @
2010-11-24 23:03 margin 閱讀(236) |
評論 (2) |
編輯 收藏
我曾問我家MM：“如果我做了一件事，大家都反對我，罵我！你可能也覺得不對，你還會支持我嗎？ ”
她說“就算是再怎么不對，我都會支持你的”
這一次，我明白了。
她是數(shù)字的忠實用戶，她是不懂什么技術(shù)。連QQ彈個QQ寵物都不會關(guān)（懶得關(guān)？！）她甚至都不知道我在做什么工作。
那天，她對我說“雖然我覺得有點不妥，但是我還是把數(shù)字卸載了”
第二天，她對我說“小豬，我在校內(nèi)上說我支持你們，好多人罵我！”
第三天，她對我說“小豬，我相信你。但是我好擔(dān)心你們會被人打敗了！”
我可愛的MM，我傻傻的MM。
相信我，我在做一件正確的事情。我不會讓你失望。
我為你而感動....
posted @
2010-11-06 01:09 margin 閱讀(90) |
評論 (1) |
編輯 收藏
難得.....終于放出來了。
哥幾個敢怒不敢言，對于x總怨言很大。用吃完晚飯出去散步半小時的方式表達(dá)無聲的訴求。
“我艸，我們這可不就像監(jiān)獄里的犯人，每天出來放風(fēng)”
“有點像”
走到鼎好，我和某童鞋看到聯(lián)想的廣告，說了句“牛B”
眾人鄙視的說，“艸，你倆真是剛放出來的，現(xiàn)在看個廣告都這么有興趣”
下周的日子還不如這周，最后說一句。哥這輩子再也不吃“吉野家”了。
posted @
2010-10-30 13:53 margin 閱讀(109) |
評論 (0) |
編輯 收藏 http://coolshell.cn/articles/2606.html
對我來說，一個好的程序員應(yīng)該是努力去追求盡可能無錯的高質(zhì)量的符合需求的代碼實現(xiàn)。 一些人也許認(rèn)為好的程序員是那些懂得多門編程語言，懂得很牛技術(shù)的程序員，是的，這在某些情況下是對的。但歸根到底，無論你用什么樣的技術(shù)，什么樣的語言，所有的程序被寫出來，其功能都要符合需求以及盡可能地健壯無錯和高質(zhì)量。 我們可以想像一下，如果一個能力普通的程序員有足夠多的時間來做測試，那么，其也可以保證他的代碼的質(zhì)量。所以，有一種觀點這樣認(rèn)為——要達(dá)到質(zhì)量高的代碼只需要有足夠多的時間來做測試。這對于以結(jié)果為導(dǎo)向的商業(yè)軟件開發(fā)中是可以理解的（我們可以看到那些制汽車的產(chǎn)商在汽車測試上花費的精力和時間就可以明白這一道理）。
但是，很明顯，所有的已經(jīng)開發(fā)出來項目都是在不完美的條件下開發(fā)出來的，一般來說，幾乎所有的項目都是在最大化程序員軟件的開發(fā)速度。而且，很多情況下，我們似乎對深度測試和壓力測試并不是很關(guān)心，所以，我們總是在祈禱并期望那些趕工出來的代碼可以正常工作，尤其是在上線的時候，這種唯心主義的價值觀更為強烈。 其實，開發(fā)速度和軟件產(chǎn)品質(zhì)量并不矛盾。好的程序員并一定是技術(shù)強的程序員，而是那些可以在不完美的工作環(huán)境下保證軟件質(zhì)量和工作效率的程序員。下面是是五個程序員可以在這種不完美的情況下做得更好的觀點（它們都和語言和技術(shù)沒什么關(guān)系，只不過是一種你的工作行為，能夠和所有的行業(yè)相通），這五個觀點也許可以讓你成為這樣的好程序員。
- 尋找不同觀點：程序員好像并不喜歡技術(shù)上有異見的人，他們特別喜歡爭論各自的技術(shù)觀點。但是，他們忽略了不同觀點的價值。任何事情都有好有壞，我們應(yīng)該學(xué)會在不同觀點中學(xué)習(xí)和平衡。這樣才會更多的了解編程和技術(shù)。要經(jīng)常在做事之前問自己和別人，這么做對不對？做完事后問自己，還可不可以改進(jìn)？努力去尋找別的不同的觀點或方法。程序員應(yīng)該經(jīng)常上網(wǎng)，經(jīng)常和同事討論不同的實現(xiàn)方法，不同的技術(shù)觀點，這樣才能取長補短。然而，在實際工作中，我發(fā)現(xiàn)程序員們并不喜歡互相請教，因為請教的人怕別人看不起他，而被請教的人總是先貶低對方的能力，哎……（參看《十個讓你變成糟糕的程序員的行為》），如果有這樣的文化氛圍的話，那也沒有關(guān)系。上網(wǎng)吧，網(wǎng)上的人誰也不認(rèn)識誰，可以盡情地問一些愚蠢的問題。呵呵。總之，一定要明白，如果某些事情只有一個觀點，那么你一定要懷疑一下了，沒有觀點和技術(shù)方案的比較，沒有百花齊放的情況，你就無法知道是否還有更好的東西。真正的和諧不是只有一種聲音，真正的和諧而是在不同的觀點聲音下取長補短，百家爭鳴（參看《十條不錯的編程觀點》）。否則，你永遠(yuǎn)都不會接受到新的觀點，也就無法進(jìn)步和成長了。
- 千萬別信自己的代碼: 在任何時候，一定要高度懷疑自己的代碼。很多時候，錯誤總是自己造成的。所以，當(dāng)出現(xiàn)問題的時候，要學(xué)會review代碼中所有的可疑點，千萬別覺得某段代碼很簡單，可以略過。事實證明，很多疏忽大意都是在陰溝里翻的船，都是那些很低級的錯誤。在查錯的過程中，切忌過早下結(jié)論，切忌四處亂改（參看《各種流行的編程風(fēng)格》），停下來，想一想，會是哪兒的代碼有重大嫌疑，然后查看一下代碼，捋一捋程序的邏輯（參看《橡皮鴨程序調(diào)試法》），調(diào)試并驗證一下程序的邏輯和變量在運行時是否是正確的。很多時候，對于那些難纏的問題，最后解決了總是因為我們開始認(rèn)真回頭審視所有的代碼。只有對自己的代碼保持著高度的懷疑，這樣我們才會想著如何讓其運行得更好更穩(wěn)定，也會讓我們在單元測試中下更多的功夫，這樣才能更能在那忙碌的環(huán)境中節(jié)省時間。相信我，在集成測試中fix bug的成本要比在單元測試Fix bug的成本大得多的多。一個簡單的例子就是memory leak。程序員對自己的程序需要有憂患意識，這樣才會越來越成熟，而自己的能力也會越來越強。
- 思考和放松: 做事前多想一想，這樣做事的時候就不會不顧此失彼，手忙腳亂，一旦事情一亂，你的心情也會更亂，于是，事情也就會更亂。最后，你只得重寫，這種事情太多了。而且，在工作中要學(xué)會享受，要學(xué)會放松心情，我并不是讓你工作的時候聊QQ，我只是說，有時候，心態(tài)過于緊張，壓力過大，你的工作成果反而更不好，從而又反過來造成新一輪的焦慮和緊張。我個人認(rèn)為，思考和放松是可以完美統(tǒng)一的，思考其實就是一種放松，停下來，休息一下，回頭看看走過的路，喝口水，登個高，看看過去走的對不對？總體是個什么樣？總結(jié)一下，然后看看前路怎么樣好走，這會你才會越走越好，越走越快。好的程序員都不是那種埋頭苦干的人，好的程序員總是那些善于總結(jié)成敗得失，善于思考，善于調(diào)整，善于放松的人（參看《優(yōu)秀程序員的十個習(xí)慣》）。不然，我能看到的情形是，你很快地把事干完，回到家剛坐下來，老板或是客戶就打電話來告訴你你的程序出問題了。總之，深思熟慮，動作會很慢，但是你可以保證你工作成果的質(zhì)量，反而能讓你更多的節(jié)約時間。
- 學(xué)習(xí)歷史，跟上時代: 如果你是從十年前開始編程的，那么，今天的這門語言或是技術(shù)會有很多很多的改進(jìn)和改善。你以前開發(fā)一個功能或函數(shù)，今天早已被集成時了語言中，而且做得比你的版本要好得多。以前你需要100行代碼完成的事情，今天只需要1行代碼。這樣的事情在未來還會發(fā)生，所以，今天的你一定要學(xué)會如何跟上時代。但是，你也不要放棄歷史，我現(xiàn)在看到很多程序員對一些現(xiàn)代的語言和技術(shù)使用的非常好，他們可以很容易地跟上時代。但不要忘了，計算機世界的技術(shù)更新和技術(shù)淘汰也是非常猛的。所以，你一定要學(xué)習(xí)歷史，這些歷史不是產(chǎn)商的歷史，而是整個計算機文化的歷史（參見《Unix傳奇》）。只有通過歷史，你才能明白歷史上出現(xiàn)的問題，新技術(shù)出來的原因，這樣才能夠?qū)裉斓倪@些新的技術(shù)更了解，也才能明白明天的方向在哪里。學(xué)習(xí)歷史和跟上時代都是相當(dāng)重要的。使用新型的技術(shù)，停下來接受培訓(xùn)，可以讓你工作得更快，更高效（參看《未來五年程序員需要掌握的10項技能》）。而學(xué)習(xí)和總結(jié)歷史，才會讓你在紛亂的世界中找到方向。
- 積極推動測試活動: 只有測試才能證明軟件可以正常工作，只有測試才能保證軟件的質(zhì)量。無論什么產(chǎn)品，都需要經(jīng)過或多或少的測試。測試地充分的產(chǎn)品或模塊，你會發(fā)現(xiàn)其質(zhì)量總是那么好，測試的不充的產(chǎn)品，質(zhì)量總是那么次。德系汽車，日系汽車質(zhì)量怎么樣，關(guān)鍵還是在于怎么去測試的，測試的是否充分。所以，在你開發(fā)軟件的過程中，如果你說你的程序?qū)懙睾茫|(zhì)量高，那么請你拿出實實在在的測試報告。在整個軟件開發(fā)過程中，做為一個好的程序員，你應(yīng)該積極地在各個環(huán)節(jié)推動項目組進(jìn)行測試活動。不要以為技術(shù)需求階段和設(shè)計階段不需要測試，一樣的，只要你要release什么，release的這個東西都需要進(jìn)行測試。技術(shù)需求怎么做測試？用戶案例就是測試案例。在軟件開發(fā)的整個過程中，保證產(chǎn)品質(zhì)量有時候比實現(xiàn)需求更重要，尤其是那些非常重要甚至人命關(guān)天的產(chǎn)品。
上面這些五個觀點都是可能讓你在不完美的工作環(huán)境中可以工作得更好，更快，更高效，希望能夠?qū)δ阌杏谩Ａ硗猓矚g迎你留下你的觀點！
（全文完）
posted @
2010-10-27 17:13 margin 閱讀(167) |
評論 (0) |
編輯 收藏
最近，某數(shù)字公司搶先出手，與本人所在的某公司在輿論等各個方面積極的互動。殃及了池魚，我等小P民天天加班，無休止加班，封閉式加班。非得弄出個啥東東出來的架勢。一個需要1個月才能弄出來的東西，讓你1個星期搞定。結(jié)果可想而知了....
其實我不是抱怨，我明白公司這么做也沒有辦法；養(yǎng)兵千日用兵一時嘛！可是，我突然發(fā)現(xiàn)自己這一年是我這一生有史以來最忙碌的一年了。轉(zhuǎn)戰(zhàn)了大半個中國，做了兩個產(chǎn)品，得到的回報卻了了。有時不禁反問自己值得不值得。。。哎，罷了！早在知道T3沒通過的那一刻我就已經(jīng)明白答案。也許回報會在不遠(yuǎn)的以后呢？！（god knows！！）
其實我真不是抱怨，我也明白短時間內(nèi)工期這么趕怎么可能寫出啥好的代碼。但是我這次是徹底發(fā)現(xiàn)自己原來平時寫的代碼是多么的好了。因為我現(xiàn)在看到自己寫出的更垃圾的代碼。本來我以為這輩子再也不可能寫出這么垃圾的代碼來了的。這次終于又讓我證明了一種不可能性。
其實我真不是抱怨，不就是每天工作12個小時嗎，不就是連續(xù)工作20天嘛，不就是吃飯都不離開座位的開發(fā)嗎？這真的沒啥，我能挺住！
其實我只是想等過完這陣忙碌以后，別讓我再維護我那些惡心的代碼，別讓我再用vs2005 debug。讓我能用全屏小寫的字母，在vim里面寫出python風(fēng)格的cpp，然后輕松一點ac去也....
這個愿望很簡單不是嗎？ 想遠(yuǎn)在深圳的同學(xué)致敬，聽說你們也很不容易！
posted @
2010-10-20 01:22 margin 閱讀(228) |
評論 (1) |
編輯 收藏
今天在 光合作用 里面待了一下午，非常棒的讀書環(huán)境。國慶期間能靜下來讀讀《數(shù)據(jù)結(jié)構(gòu)》太愜意了。
感謝MM的建議和耐心陪伴....
晚上由于太無聊了，上論壇上逛了逛。想想搜索了一把關(guān)鍵詞是 XX 密碼框。
哈哈，看著各種帖子里面大家的討論和神秘高人的爆料，以及某些高手的分析。著實讓我開心了一番，也讓我回想起三年前的種種經(jīng)歷。
1.某些高手們分析的都差不多已經(jīng)很徹底了，可能有一些東西還有些誤解，但是內(nèi)存盜號貌似不成問題。
2.作為一個逆向者有些想法，總是很奇特。但是開發(fā)也有開發(fā)的無奈，有些事情在不清楚的情況下，說開發(fā)能力不行是有點可笑的。
3.想想當(dāng)年為了對抗某款木馬，想出來的方法。拍著胸脯說三個月內(nèi)不可能被攻破。哈哈，果然這個算法直到2年后才逐漸浮出水面。
4.看到別人分析出自己的想法，自己不會很生氣，反而會感覺很高興（當(dāng)然如果說這個算法太爛了，也是會郁悶一下的）。
5.某些同學(xué)可能還是要繼續(xù)忙了，不過已經(jīng)與我無關(guān)啦。我在這毛都沒有的地方，對他們說：辛苦了！
posted @
2010-10-06 00:35 margin 閱讀(165) |
評論 (0) |
編輯 收藏
慶祝一下，去睡覺！
posted @
2010-10-05 01:12 margin 閱讀(112) |
評論 (0) |
編輯 收藏此提一共有三種解法：
1.枚舉
最樸素的算法，但是一開始我居然不知道如何來枚舉。大概的原理是：以位置1,1開始變化。得到16種位置的最小解法，然后選最少的一個就OK。
2.BFS
一開始，我想到的就是這個解法。原來還認(rèn)為是枚舉，但是仔細(xì)看看應(yīng)該是BFS。因為是記錄給自己看的，所以解法不說。
3.直接給結(jié)果
這題和之前的黑白子差不多。不過那題我是BFS過的。所以這題，想看看枚舉人家怎么做的。但是沒想到搜索到了這種解法，對比了一下discuss和他的講解。下面將代碼貼出來。
1// http://m.shnenglu.com/Yusi-Xiao/archive/2010/07/05/77385.html
2// 先看一個簡單的問題,如何把'+'變成'-'而不改變其他位置上的狀態(tài)?
3// 答案是將該位置(i,j)及位置所在的行(i)和列(j)上所有的handle更新一次。
4// 結(jié)果該位置被更新了7次,相應(yīng)行(i)和列(j)的handle被更新了4次,剩下的被更新了2次.
5// 被更新偶數(shù)次的handle不會造成最終狀態(tài)的改變.
6// 因此得出高效解法,在每次輸入碰到'+'的時候, 計算所在行和列的需要改變的次數(shù)
7// 當(dāng)輸入結(jié)束后,遍歷數(shù)組,所有為奇數(shù)的位置則是操作的位置,而奇數(shù)位置的個數(shù)之和則是最終的操作次數(shù).
8// PS:該題不會有"Impossible"的情況.
9
10#include <stdio.h>
11
12#define Len 4
13
14void main()
15
{
16
int handles[Len][Len] = {0};
17
int i, j, k, step = 0;
18 char c;
19
20 // 核心算法，統(tǒng)計翻轉(zhuǎn)的總次數(shù)
21 for (i = 0; i < Len; ++i)
22 {
23 for (j = 0; j < Len; ++j)
24 {
25 scanf("%c\n", &c);
26 if ('+' == c)
27 {
28 handles[i][j]++;
29 for (k = 0; k < Len; ++k)
30 {
31 handles[i][k]++; // 這種算法重復(fù)計算i,j 處，但是對于只需要判斷奇偶來說無所謂
32 handles[k][j]++;
33
}
34 }
35 }
36 }
37 // 統(tǒng)計奇數(shù)的個數(shù)
38 for (i = 0; i < Len; ++i)
39 {
40 for (j = 0; j < Len; ++j)
41 {
42 if (handles[i][j] % 2)
43 {
44 step++;
45 }
46 }
47 }
48 printf("%d\n", step);
49
50 // 打印奇數(shù)的位置
51 for (i = 0; i < Len; ++i)
52 {
53 for (j = 0; j < Len; ++j)
54 {
55 if (handles[i][j] % 2)
56 {
57 printf("%d %d\n", i + 1, j + 1);
58 }
59 }
60 }
61
}
ps.
1.這個算法居然也用了64ms。
2.一開始用的scanf("%c", &c);忘記了\n,錯了。然后居然牛逼的想到scanf("%c\n", &c);哈哈！
3.鏈接中的作者有部分說錯了，在上面的注釋我更正了一下。
4.不知道為啥poj的域名變成poj.org....
posted @
2010-10-02 16:52 margin 閱讀(568) |
評論 (0) |
編輯 收藏
在用qsort的時候 查了一下msdn，看到include里面是stdlib.h 或者 search.h。然后隨便的用了search.h。沒想到在提交的時候連CE兩次，一開始我還以為我其他的地方語法有問題。在VC6上以.c結(jié)尾的形式編譯，應(yīng)該是能過oj上的編譯器的啊！最后改了兩次，不行了用小號上。終于發(fā)現(xiàn)是頭文件的問題。
在VC6上編譯通過但是OJ上CE的案例，總結(jié)一下：
1.頭文件：search.h頭文件是c++的庫
2.強制類型轉(zhuǎn)化: 在C中應(yīng)該這么寫b = (int)a,而在c++里面可以寫成 b = int(a)
3.new文件時，應(yīng)該用.c結(jié)尾，這樣能保證變量不會在中間定義。
posted @
2010-09-26 00:00 margin 閱讀(188) |
評論 (0) |
編輯 收藏