其他

摘自http://nmap.org主機發現主機發現有時候也叫做ping掃描，但它遠遠超越用世人皆知的ping工具 發送簡單的ICMP回聲請求報文。使用者完全可以通過使用列表掃描(-sL)或者 通過關閉ping (-P0)跳過ping的步驟，也可以使用多個連接埠把TPC SYN/ACK，UDP和ICMP 任意組合起來玩一玩。這些探測的目的是獲得響應以顯示某個IP地址是否是活動的(正在被某 主機或者網路裝置使用)。 如果沒有給出主機發現的選項，Nmap 就發送一個TCP

一直以為 int a[256]={0};是把a的所有元素初始化為0，int a[256]={1};是把a所有的元素初始化為1.調試的時查看記憶體發現不是那麼一回事，翻了一下《The C++ Programming Language》總算有定論。PDF的竟然不然複製，就把它這章翻譯了，如下5.2.1   數組初始化數組可以用一個列值來初始化，例如         int v1[] ={1,2,3,4};         char v2[]={'a','b','c',0};當數組定義時沒有指定大小，

當我們看到隊友遇到困難的時候大家並沒有齊心協力來協助，他們在想“嗯，這是他們的事情”，很多人是這樣。這時，如果你讓他一個月內什麼事情都可以不幹，甚至可以呆在家裡不用來上班，他下個月還是會心安理得的來領工資，很多人並不考慮付出與報酬的關係，同樣，很多人也不會去考慮付出與收穫的關係。在項目的管理上多數人主張要有明確的分工，但很少人能夠解決明確的分工所帶來的在時間軸上階段性的任務量不均衡的問題。幾乎沒有一個項目在分工上能夠至始至終保持一種並行的關係，而這種並行關係的力量又是相對的均衡。所以明確的分工在

領導判斷誰對誰錯，不是看具體的事情，他沒有時間去看具體的事情，大多數是根據對這個人的印象，以及具體的指標。即使我們很多人認為考核的一些指標並不能作為衡量一個人的能力和貢獻的標準，但沒有任何一個人能夠提出一個可行的更完善的考核標準。在沒有一個更好的衡量標準出現前只能採用目前最好的標準。就像科舉制度，我們很多人批判，但是它依然延續了幾千年，又如現在的教育方式亦被廣為批判，但是它還是依然執行，沒有更好的方式之前它依然是無可替代的。

如果有人要你推薦一名優秀的程式員，你會想到誰？你認為你自己是嗎？你的評判標準是什嗎？思考了這個問題，我意識到程式員可以以各種方式做到優秀。所以我向你推出“四種類型的優秀程式員”並附上插圖。1. 哲學家哲學家喜歡編寫定義良好、結構良好的漂亮代碼。程式構思好後，哲學家會花大量時間在方案的優雅性、健壯性和靈活性上。一個星期不談“最佳實務”，哲學家就會覺得渾身不爽。動力嚴密控制帶來安全，哲學家的終極動力源於此。組織良好的，可預測的系統，清晰的設計原則是哲學家的理想境界。混亂是絕對不能容忍的。秩序產生美。

有位職業經理這麼說：“技術是很容易抄襲的，而企業文化、人才管理這些軟實力才是企業的核心競爭力”。對此我很不同意。當然不同的角度有不同的理解。如果站在他們公司的角度，他的說法也許是合理的，因為他們的公司被定位為一個服務型的公司，它更注重的是IT技術服務，而不是IT技術本身。但是如果站在IT業或者中國IT業的角度看，這句話便恰如其分的代表了中國人、中國IT業的悲哀！中國為什麼在技術上趕不上別人？抱有這種思想便是頭等大害！中國一直在學習和掌握別人的技術，中國沒有自己創新的、領先的技術，換個角度說我們就

文章目錄 編譯的時候要加 :                    -lcppunit -ldl1.    CppUnit::TestFixture2.    setUp3.    tearDown4.    CppUnit::TestReuslthttp://write.blog.csdn.net/postedit5.    CppUnit::TestResultCollector6.    CppUnit::TextOutputter9.   

      項目開發過程中不能過於倚重某一個或某幾個人，也不能忽視某一個或某幾個人。雖然團隊成員能力參錯不齊，但專案經理必須運用智慧加以調整使組員的分工基本是平衡的，因為過於倚重或忽視的不平衡狀態將給項目進行帶來極大的風險。忽視的人會因失去信心而消極或離職，過於倚重的人會因過於自信和高估而向上司挑戰或跳槽。任何事物最安全的狀態是平衡狀態，不平衡必將帶來難以掌控的風險。    

技術上無形的東西比有形的東西要重要，管理技術比技術本身要重要。有形的東西，比如JAVA、C++文法及功能，業務電信商務程序，這些東西我覺得大多數人學一學，或者培訓一下，都很容易學會，在這些東西上你實際獲得不了競爭優勢。什麼是無形的東西？比如JAVA、C++的設計思想，一些編程思想、編程規範，對一種業務的設計方案，創新設計的能力，這些看不見的東西，不易領悟到的東西，大多數人都是很難學習和掌握到，能夠掌握到這些東西才能提高你的核心競爭力。管理技術指技術人員對其技術行為的管理，對於大多數程式員他只關心

如果說大家在完成主要工作的空閑時間完成詳細設計的補充，那麼大家即使閑在那裡看電影打遊戲也不會去做。因為他們覺得這是伸縮性太強的工作，他們可以做的多也可以做的少，可以做得好也可以做得不好，甚至可以做也可以不做。這種思想主導了他們對這種工作的認識，所以說這種分工是無效的。組織也體現了人的社會性，如果在沒有任何引導、監督、強迫、懲罰或獎勵等措施的管制下，個體很難發揮其社會責任心。個體不會自發、自覺、自律地去維護其集體利益而付出超出平均勞動的行動，而且不可否認大多數個體有儘可能地減少其勞動付出的潛在意識

      大多數程式員都有一種自信、獨行的特質，他們總是深信自己的代碼品質，所以他們很不樂意接受別人對他提出異見，然而提出異見正會使程式的功能更加完善、更有保障，即便有時也會有一些消極的作用，但是大的方向和方法上是正確的、可靠的；他們只注重自己的代碼，所以他們總是樂在其中也深陷其中，他們很討厭寫文檔或配合他人做瑣碎的事情，然而這是一個團隊合作的基本工作，他們做的程式以外的其它東西實際上同程式一樣重要，同樣對團隊是有益的。    

每次討論問題的時候，大多數人都是在說“別人應該怎麼做”，很少有人想“我應該怎樣配合別人去做”。每個人都想讓自己成為主導，他希望問題的解決方式能夠向有利於他的方向靠近，他更關心的是自己的問題而不是組織的問題。人類自私的天性和狹隘的局部觀又想主導整體問題的思想是組織上矛盾產生的根源。這也是問題難以解決的關鍵所在，難以解決的關鍵因素是人，或者更具體的說是人的思想。事好做，人難管，這是專案經理的苦惱所在。我常常在討論問題的會議上看到這個要這樣做，那個要那樣做，而兩者的建議往往是矛盾的。我所見到的專案經理

規則：1，對於union，對齊的大小是最大的基本元素的對齊大小；對象的大小必須是該基本元素大小的整數倍；2，對於struct，對齊的大小也是最大的基本元素的對齊大小，對象的大小需要考慮元素的對齊，並且需要是最大基本元素的整數倍；同時有#pragma pack修飾的情況，關於struct請詳細參考另外一個文章。3，這裡所說的struct和union的對齊，是指其作為其他複雜物件中的元素的時候要求的對齊，對於本身大小的計算並沒有關係。本身的大小隻和其所包含的基本元素的對齊有關係。例子一：union

一方面需要從統一點提出解決方案，一方面需要執行點反饋問題。統一點無論多強大，也對總體必然有遺漏的地方。如果完全由統一點提出解決方案的話，那麼必須對統一點的負責人素質要求非常高，實際上這一點很可能成為瓶頸。走統一的方向不變，但是對統一帶來的缺陷或漏洞必須修補。執行點的反向作用是很重要的補充。這種機制實際上使統一點和執行點都具備主動性，是雙向主動，而不是由統一點主導的單向主動。人類社會發展的過程是一個不斷創造、不斷毀滅、不斷更新的過程，但是總體上是進步的。這說明從宏觀上看是直線的上升，從微觀上看是曲

關於“改”的問題很多人一提到“改”就很反感、很排斥、很拒絕，難道“改”就這麼的令人厭惡嗎？不是的；又難道我們就可以永遠的拒絕掉“改”嗎？是不能的。我們一直都是在“改”中生存著，我們每天都是這樣：在反反覆複的修改客戶的需求，在無可奈何的修改我們的bug。現在我們又在做一個大的系統，說是兩個系統的融合，無非就是兩個系統的改造，是“大改”，我們誰又能跳得出去呢？從進公司到現在我發現我們的絕大多數時間都是在“改”，新的東西沒有多少，都是在不斷的改進以適應變化，這就是我們的工作！而且不僅是在這裡，在其它地

把問題消滅於萌芽狀態--不需要你有力挽狂瀾，扶大廈於將傾的本領，更需要你有未雨綢繆，防患於未然的意識。不要在無力回天的時候爆料出你的程式有一個鬥大的漏洞，這對於專案經理來說無疑是一個晴天霹靂。有位大師說過：人類最大的毛病是自大、懶惰、怕麻煩！是的，這是人類普遍的毛病，當然，也是軟體開發人員經常會犯的毛病。知道有一些問題，或者說一些隱患存在，而由於自己的懶惰和怕麻煩，不去發現，不去解決，任它繼續存在，這樣的結果是問題越積越多，越積越大，越來越嚴重，到最後難以解決！這是很多軟體開發過程中存在的一個普

管理很大程度上是協調，協調就是要顧及多方的利益。大多數員工只是站在自己的角度考慮問題，有益於自己的事情就做，無益於自己的事情就很排斥，這是一個普遍的現象。管理者就要處理這樣的事情，要折中處理或適當處理。這當然要傷害一些人的利益，但這是必然的，人人都想滿足自己，但滿足人人又是非常困難的。管理是什嗎？管理不僅是制定計劃、制定規範或者制度，管理更重要的是要監督、執行。可以說制定計劃和規範易，具體監督和執行難！計劃和規範制定的再好，如果不能嚴格執行，及時監督，所有的計劃和規範就不能起到效力，那麼最終的目

在測試的過程中，我們必須面對一個問題，就是修改與測試的交錯流程。我們可能面臨的情況是這樣：測試、修改、再測試、再修改、繼續測試、繼續修改，直到上線。這樣的特點是反覆測試反覆修改，直到沒有問題為止。也許我們的測試人員會問：為什麼那麼多bug不能一次性修改完畢，讓我們對一個功能反覆的測試？！那麼我要問一下，如果所有的bug都在測試之前一次性修改完畢，那麼測試的價值在哪裡？就是走一個過場嗎？——誠然，不是這樣，測試的意義是在系統正式運行前發現所有的問題並提交開發解決之，測試的價值在於保證了系統在上線後

在很多時候大家不要埋頭苦幹，也許你是在走錯路。在一個團隊裡，我們需要齊頭並進。給遠方樹立一個燈塔，大家朝同一個方向前進，而不要“走自己的路，任別人去說”。無論大家在做哪一塊東西，但時刻得記住，我們需要朝同一個方向前進。所以在做事的過程中，不要怕麻煩，或者不好意思，可以多問問別人，多看看文檔，雖然花了時間，但是可以很好的防止你走彎路。技術本身是沒有任何價值的，技術只有轉換為商品以後才具有價值。而轉換為商品的過程是需要靠管理來實現的。管理做好了，技術才能發揮到最大價值。在一個項目中，技術固然重要，但

      開發人員不應告訴QA他的程式是如何?的，只需告訴他實現了哪個需求，以及什麼功能，可以建議性地提出這些功能可以通過什麼方式來檢驗。開發不可告訴QA某個功能如何去測試，這一條是團隊合作的禁忌，QA是通過對需求的分析和對設計的理解來制定自己的測試計劃，包括測試方案、測試方法、測試資料、測試載入器。開發和QA都是基於需求，他們在分工上是串列關係，但在功能上是並行關係。