摘要: 記 得幾年前如果你需要添加一些互動元素到你的網站中用來改善用戶體驗？ 是不是立刻就想到了flash實現？這彷佛年代久遠的事了。使用現在最流行的web技術 HTML5，CSS3和jQuery，同樣也可以實現類似的用戶體驗。而且使用這些特性將會比使用flash更加有效。也許你可能剛知道Adobe停止開 發移動版flash的消息，雖然在桌面中我們還擁有大量的flash的應用，但是隨著HTML標準的完善，...
閱讀全文
摘要: http://www.oschina.net/news/23206/25-useful-html5-cheat-sheets-and-tutorials-for-web-developerweb開發者必須盡快熟悉并使用起HTML5，因為它在web端開發的發展趨勢已經明朗，可以用來創建豐富多彩的效果。使用HTML5還是有一些復雜的，所以本文介紹了25個優秀的HTML教程及小手冊，歡迎大家使用。Mak...
閱讀全文
小C所在公司目前現狀：
開發人員30人左右，項目型團隊。
測試人員：小C、本科學歷、測試工作經歷1年；
職責范圍：編寫測試用例，測試執行，編寫幫助文檔、產品對外溝通和培訓等；
抱怨理由：工作量大，經常加班，無加班費，工作壓力大，薪水不見長；產品出了問題首先責問測試人員；在這個公司沒學到什么知識，目前所做的也都是一些苦力活；不
知道做這些有沒有什么發展，現在很迷茫，想辭職，又怕錯過這個發展機會。。。
小C的問題很普遍，雖然以前的答復都類似，但還得重新組合一下回復的思路：
首先，小C是否明確了自己在測試行業里的發展規劃，如果已定位測試職業規劃，那么就不考慮該跳槽，換行業的思考；
1、工作量大，經常加班，無加班費；
偶認為是第一個問題是最主要的，為什么工作量大，先分析清楚這個，然后再找對策；
著手點在小C的崗位職責是否明確，小C是否知道哪些工作是自己份內的事，哪些是份外的事情；如果是份內的事情，工作量大是經常還是偶然，換個角度去思考問題，從自己本身問題找起，如果有公司流程和管理混亂或其他原因導致，那么就可以跟領導說個1、2、3來，這點是小C自己要能分析和總結出來的，別人幫不了；如果是份外的事情導致自己工作量大，那么就需要溝通和協調；
總的來說，小C應該把自己的工作量化出來，哪些事該做？工作計劃和時間安排，一一羅列出來，即便變化很大，也不能失去工作計劃這個主線；事情清楚了，給領導也能有一目了然的交代和認知，
偶想小C加班的事情領導肯定也看在眼里，如果你能把這些信息反饋給上級并能讓自己的作用在這個崗位上發揮到重要的作用上，那么薪水報酬自然是領導應該去考慮的問題，小C也就不會在抱怨了，動力有了工作也就不會那么壓抑了；
2、工作壓力大
一方面說明小C責任心強，也許還有點不自信都在里面，偶想小C要明確的告訴領導，產品出了質量問題，最主要的原因不能落在測試人員身上，這是測試行業里最明白和淺顯的道理，不再詳細討論，小C應該做的是總結原因，修改用例，避免下次再出現這樣的問題遺漏現場；小C也不要太在意這個信息的反饋給自己心理帶上枷鎖，因為測試行業本身就在夾縫中生存和發展，心態要平和一些；
3、沒學到什么知識
老話說：平凡的崗位上也能出人才。就看什么樣的人、用什么樣的態度和方法去面對這個平凡的崗位，從小C反饋的信息來看，能力還是比較全面，領導也安排了很多資料的編寫這樣的工作，說明小C在這個團隊里還是有事可做的，事情雖然看上去比較簡單但如果要做好這些事情，還真不是那么容易，對小C來說也是一個很好的鍛煉機會，先跳槽之前，先問問自己，我真的滿足了這個崗位需求？我真的把工作做得很好了？我在這個團隊里沒有發展空間了？每個公司都會有這樣或那樣的問題，但首先我們先考慮自身的問題，先想好，然后再做。
4、目前的待遇和付出不成比例
80%的人或許都有這樣的想法，首先還是要綜合分析一下原因，橫向、縱向有個比較，個人的發展和公司的發展是緊密相聯的，你是否是以主人翁的態度去面對這份工作，你的領導認為你還有哪方面的不足和需要提高的地方？你是否跟領導有很高的溝通？每個公司都有漲薪水的要求和規則，你是否符合條件？
拋開以上問題外，如果問題真出在公司環境上，在工作中無法尋找到興趣和樂趣的話，那就把工作當成一個純粹的工作。在這個崗位上暗自努力，積累經驗，做好下次跳槽的準備！
解決這個問題還有一個辦法就是小C在工作之外去求職，經過求職和面試的過程，會讓你獲得一些感悟，即保住了目前的工作，也幫助自己認識到自身的優點和不足，然后再在工作和學習中去改進自己的缺點和不足，此意見僅供參考~！呵呵，如果被公司領導發現你在另謀出路，也許他對你的信任度又將降低了~！
總之，遇到問題的時候辦法，先從自身問題開始反省，然后再分析外部原因，換位思考，做個有心的人~！
大多數數據庫都自帶了同步方案，但通常是同步到同一類型的數據庫。在一些特定的情況下，我們可能希望把數據從一種數據庫，同步到另一種數據庫，以便進行數據分析、統計、挖掘等，或是完成實時監控、實時搜索等服務。
本文介紹的就是這樣一個方案，把數據從NoSQL數據庫ttserver同步到MySQL上。
數據的同步過程基本上可以分解成：獲取、解析、識別、處理。
獲取同步（replicating）過程基本上就是處理高性能網絡交互、各層通信協議、基于安全考慮的身份驗證等問題的過程。解析（parsing）過程主要處理具體數據結構，由分派器（dispatcher）分派給具體的識別器（recognizer）進行識別。最終由處理器調用數據訪問層完成整個過程。基本過程可見下方草圖：
以上只是一個簡化的草圖，實際完成的時候，還有很多細節需要處理，如，
1）快照點的選擇，以及生成快照點的方案。不穩定的數據是沒用的；
2）協議、數據結構的可配置化。不同的場景下只需要簡單配置，就能滿足具體業務；
3）對前后端數據服務的抽象。只有抽象化，才能讓它成為一個有生命力的方案；
4）高處理能力。異步、非阻塞、多worker、操作合并；
5）考慮對協議升級的兼容方案；
6）可支持前后端數據遷移、數據分片；
7）前后端多實例同時使用；
8）全局同步與增量同步方案同時支持，新同步點支持；
9）各種可能的出錯：網絡、數據、服務等處理、監控、告警；
10）穩定性、可用性；
11）完備的統計數據。方案做得怎么樣，總要有數據才好說話吧：）
順帶把部分初期概念設計圖放出來。后來已經有一些演變，但只是少數環節上。在大部分的環節上，基本思路沒有太大的變化。
經過一段時間的奮戰把方案實現出來，功能驗證也比較順利通過了，實戰又將跑得怎么樣？具體業務及性能數字未經同意不準備在此公布，但可說側面說一下。目前，該方案上線應該已經將近一年，除了少數幾次前端遷移以外，未停過服。性能方面，一年后，在業務已經有量級發展的情況下，該方案仍能滿足需求。
另外，雖然命名為tt2mysql，我從未把該方案當成是數據庫之前的同步方案。以前說過會把東西總結出來，一直太懶，翻到了就寫一下。
大家討論使用Gearman做分布式處理時，各機需要注冊一個獨立的job作為信息反饋，但是為了方便，Gearman::Worker腳本register_function代碼又要通用，于是想到了使用各自的ip地址作為job命名~
那么怎么在worker腳本里獲取本機ip作為func呢？
第一種辦法，最簡單的，調用shell：
| $ip = `ifconfig eth0|grep -oE '([0-9]{1,3}\.?){4}'|head -n 1`; |
注：這里輸入是固定的，所以簡單的[0-9]{1,3}了，如果是在web程序等地方驗證ip，需要更嚴謹！
或者
| $ip = `ifconfig eth0|awk -F: '/inet addr/{split($2,a," ");print a[1];exit}'`; |
好吧，這樣顯得太不perl了，而且頻繁的調用外部shell不太好，第二種：
open FH,"ifconfig eth0|";
while(<FH>){
last unless /inet addr:((\d{1,3}\.?){4})/;
print $1;
} |
看起來稍微perl了一些，雖然實質跟上面的調用shell和grep法是一樣的。
第三種，更perl一點，純粹讀文件：
open FH,'<','/etc/sysconfig/network-scripts/ifcfg-eth0';
while(<FH>){
next unless /IPADDR\s*=\s*(\S+)/;
print $1;
} |
進一步的，如果不一定rh系，還要去讀/etc/issue，確定網絡配置文件到底是/etc/sysconfig/network-script/ifcfg-eth0還是/etc/network/interfaces還是其他，然后根據不同發行版寫不同的處理方法……額，這是打算自己寫模塊么？
好吧，大家來充分體會CPAN的魅力，去search一下，找到一把Sys::HostIP、Sys::HostAddr、Net::Inetface等模塊。第四種：
use Sys::HostAddr;
my $interface = Sys::HostAddr->new(ipv => '4', interface => 'eth0');
print $interface->main_ip; |
不過進去看看pm文件，汗，這幾個模塊都是調用ifconfig命令，不過是根據發行版的不同進行封裝而已。
還有辦法么？還有，看第五種：
| perl -MPOSIX -MSocket -e 'my $host = (uname)[1];print inet_ntoa(scalar gethostbyname($host))'; |
不過有童鞋說了，這個可能因為hostname的原因，導致獲取的都是127.0.0.1……
那么最后還有一招。通過strace ifconfig命令可以看到，linux實質是通過ioctl命令完成的網絡接口ip獲取。那么，我們也用ioctl就是了！
如下：
#!/usr/bin/perl
use strict;
use warnings;
use Socket;
require 'sys/ioctl.ph';
sub get_ip_address($) {
my $pack = pack("a*", shift);
my $socket;
socket($socket, AF_INET, SOCK_DGRAM, 0);
ioctl($socket, SIOCGIFADDR(), $pack);
return inet_ntoa(substr($pack,20,4));
};
print get_ip_address("eth0"); |
這樣的好處，就是只調用了核心模塊，在分發腳本時，不用連帶安裝其他模塊。
注：這個其實是根據網上有的一個py的腳本修改的，py版如下：
#!/usr/bin/python
import socket
import fcntl
import struct
def get_ip_address(ifname):
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
return socket.inet_ntoa(fcntl.ioctl(
s.fileno(),
0x8915, # SIOCGIFADDR
struct.pack('256s', ifname[:15])
)[20:24])
print get_ip_address('eth0') |
現在先來總結一下到底上面說的模型存在著哪些問題：
1、客戶生氣地說：這個產品好像不是我們想要的吧！早知你們給我這樣子的產品，我才不會下單了，你們也早點跟我說這個產品是這樣子，到現在才給我看，浪費我時間，精力，我不買了?。蛻舻浇桓逗髞戆l現產品與當初他們提的需求不一致，所以很生氣，后果很嚴重）
2、設計團隊激動地說：都開發了這么長時間了，你們還要改功能加功能啊，這樣子會影響到很多其他功能的，會影響最后發布時間的，而且最后的質量如何，我不能保證。（老兄，我出錢買你們產品的好吧，我想加什么功能改什么功能當然得給我弄好，不然我不付錢了?。?/p>
3、開發人員暴跳如雷地說：你們這幫測試，早不提晚不提，總是在最后要發布前給我們提這么多Bug，是不是存心給我們找茬??！要是不能準時發布，你們負責啊?。?strong style="word-break: break-all; line-height: normal !important; ">測試人員委屈地說：我們也想能早點發現這個Bug，早點修好這個Bug啊，但是之前你們也沒我Build測啊！）
就這樣，不斷地出現相互的抱怨，也就是所謂的矛盾，哲學上說，矛盾是事物發展的動力，所以這些矛盾的出現，也就是預示著，我們需要有解決這些矛盾的方法，很慶幸，我們的很多前輩已經幫我們解決了這方面的問題，準確地說是從理論上解決了這種問題，且聽我慢慢道來。
首先，對于客戶能否得到自己想要的產品這個問題，以前得不到的原因無非就是兩點：
第一個就是我們一開始設計的需求點其實跟客戶所想要的需求不一致。這一點，我們可以通過需求設計完成后馬上跟客戶確認就可以解決。
第二點就是客戶只能等到最后時刻才能看到這個產品，也就意味著，即使他們發現自己以前的想法是不對的，想要改一下自己的想法卻來不及了，因為產品已經出來了，再去改可能又要等很長時間了，這個誰也拖不起。這一點，我們可以通過經常給客戶交付一個可用的Build，讓客戶去看已經實現的功能，來研究是否還需要更改。
而對于我們的設計團隊來說，上面的第二點也正好可以解決他們的問題，由于有可用的Build，所以我們設計好的功能一做完就可以馬上讓客戶看到，一旦要修改些什么，就不會再像以前那樣由于所有功能點都做完了，改一個就牽一發而動全身了，這點也類似之前說的，一個Bug發現的越早修得成本越低。
而對于咱們的開發人員和測試人員而言，為了幫助客戶得到自己想要的產品，也需要做些改變，不過也很簡單，幾句話而已，開發完成一個功能以后，測試人員就要測試這個功能，然后開發人員需要把發現的Bug馬上修掉，最后測試需要把修復的Bug確認修復。這樣子的話，就可以解決以前最后階段才能開展測試，才能發現大量Bug，導致發布成本增加、延期等不確定因素的發生。
當然，這里還有一點必須說一下，即使采用了新方法，成本增加，時間延期這種事情還是有可能發生，但是新的方法可以讓你預測到可能發生的成本與時間問題，不會像以前那樣到最后時刻才會發現，這樣子對于領導層做決策還是會有很大幫助的。
講到這里，大家應該發現，測試流程已經完全與開發流程并行了，之前說的W模型雖然也會有并行，但是只是屬于“偽并行”，因為它需要一個階段結束才能進行下個階段，比如開發完所有的功能以后才能開始測試，而對于這個模型，測試自始至終一直在參與著測試，不會去管哪個階段是否完成，只在乎哪個功能已經設計好，已經開發好。對于設計好的功能，測試里也有專門的設計測試工程師（Design QA）去專門檢查這個設計是否符合客戶的要求，甚至會去和客戶做溝通；對于開發好的功能，一方面代碼完成后開發需要馬上進行單元測試，然后專職測試人員拿到Daily Build以后就要馬上常規測試，看看是否工作，發現嚴重Bug馬上提上去讓開發修；最后所有功能都已經確認和測試完畢后，測試人員還要再繼續進行集成測試、系統測試和壓力測試等等；甚至到了后來的維護階段還需要測試人員繼續參與，因為很多技術支持人員對產品沒有測試人員了解地多，所以碰到難的問題，還需要測試人員的幫忙。
所以從一開始的設計到最后的發布，測試人員一直全程參與著，這個跟以前的模式已經有了非常大的改變了，對測試人員的要求和壓力已經是不可同日而語了。這個新的模式也就是敏捷測試模式的雛形了，當然還并非完全的敏捷測試模式，所以我暫時先把它稱之為準敏捷模式。
既然有了準敏捷模式，那什么才是真正的敏捷測試模式呢？呵呵，還是聽下回分解吧。
?。ㄎ赐甏m）
一、負載壓力測試概述
系統的負載壓力是指系統在某種指定軟件、硬件以及網絡環境下承受的流量，包括并發用戶數、持續運行時間、數據流量等等，其中并發用戶數是負載壓力中比較重要的指標。
負載壓力測試基礎概念
負載壓力測試是指在一定約束條件下測試系統所能承受的并發用戶量、運行時間、數據量，以確定系統所能承受的最大負載壓力。例如當一個系統在少量用戶同時使用時，系統能夠正常運行，但當有大量用戶同時使用，可能會出現功能失效、性能衰退，甚至系統崩潰的現象。
負載壓力測試是性能測試的重要組成部分，它包括并發性能測試、疲勞強度測試、大數據量測試等內容。
二、負載壓力測試監理工作重點
負載壓力測試實施主要包括：測試計劃，測試需求分析，測試案例制定，測試環境、工具及數據準備，測試腳本錄制、編寫與調試，場景制定、測試執行、獲取測試結果、結果評估與測試報告等步驟。下面將按照測試實施的步驟詳細論述各步驟監理的工作重點。
● 測試計劃
制定一個全面的測試計劃是負載測試成功的關鍵，一個明確、清晰的測試計劃將確保制定的方案能夠完成負載壓力測試的預定目標。監理工程師在審查測試計劃時，需要注意以下幾點；
1）測試計劃中所制定的目標是否具有可度量性
測試計劃中除了確定負載壓力測試的一般性目標，還應以可度量指標制定更加具體的測試目標，并明確的區分可接受和不可接受的測試結果的標準。例如，一個明確的測試目標可以是最終用戶的響應時間等指標。
2）測試計劃中的指標是否符合合同、初步設計或其他相關文件的要求
監理工程師在審查測試計劃時，不僅要考慮測試目標的可度量性，還要考慮測試計劃中提到的指標是否符合合同、初步設計或其他相關文件的要求。如果承建單位提交的指標與其不符，則需要監督其整改，直至符合要求。
● 測試需求分析
監理工程師在審查測試計劃時，應依據前期在項目實施過程中了解到的相關資料，判斷承建單位提交的測試需求是否合理。在判斷過程中，監理工程師在了解80-20等原理的基礎上，判斷承建單位制定的指標是否符合項目的實際情況，是否能夠滿足項目的實際需要。
● 測試案例制定
監理工程師在審查測試案例時，應關注測試案例的各項內容，包括案例名稱、案例描述、并發用戶數、網絡環境、場景、測試指標等。
1）案例描述中應明確在本案例測試過程中，必須的操作步驟；
2）并發用戶數應清晰描述初始用戶數、用戶增長模式、運行時間、停止模式、考慮思考時間等內容；
3）測試指標中應為可度量的指標。例如：事務平均響應時間小于5秒，事務通過率大于95％，CPU使用率低于60％，內存使用率低于70％等。
● 測試環境、工具、數據準備
監理工程師在本環節，需要注意承建單位搭建的測試環境與真實使用環境的區別，注意承建單位初始測試數據的準備情況。此外，某些特殊系統還需要考慮其在真實環境中的表現。例如，在測試殺毒軟件的掃描速度時，硬盤上布置的不同類型文件的比例要盡量接近真實環境，這樣測試出來的結果才具有實際意義。
● 測試腳本
目前，很多軟件開發項目都是一個比較龐大的系統工程，它由多個子系統構成。一般來說，各子系統分別由不同的承建單位開發，在測試過程中可能需要與其它系統發生交互，所以，監理工程師需要提醒、監督承建單位，測試腳本的錄制、編寫及調試工作，不僅僅要考慮到自身系統，還要考慮到相關的其他系統。例如，很多應用系統的負載壓力測試的測試步驟就需要通過身份認證，這就需要承建單位及時與身份認證系統開發商溝通，共同做好腳本。
● 測試執行
測試執行時，監理工程師應在現場旁站，及時記錄測試中發現的問題，并與已經通過審核的測試計劃、測試用例進行比較，確定系統是否實現預計的測試目標。
● 結果評估與測試報告
測試完成后，監理工程師針對發現的問題，督促承建單位進行整改，并適時開展二次測試，直至其通過負載壓力測試并出具測試報告。然后，監理工程師、業主單位代表、承建單位項目經理將在測試報告上簽字確認，并作為系統開展單項驗收工作的一個必備的前提條件整理、歸檔。
三、結束語
負載壓力測試作為系統性能測試的一個重要組成部分，有著十分重要的意義。它有助于確認被測系統是否能夠支持性能需求，以及預期的負載增長等。監理工程師通過審查測試計劃、測試案例、測試環境及腳本，旁站測試執行，對系統的性能進行質量把關，確保系統的建設能夠符合預期的建設目標，為最終的竣工驗收打下堅實的基礎。
前言：前一篇分享了Oracle環境下的環境搭建和恢復，這一篇分享下DB2數據庫的環境搭建，歡迎拍磚。
一、搭建測試環境：
?。?）新建數據庫，DB2安裝完成之后，在開始菜單中查看對應的信息，步驟是“開始”-->“程序”-->“IBM DB2”-->“DB2COPY”-->“一般管理工具”-->“控制中心”，如下圖所示：
圖1，DB2啟動頁面
?。?）打開控制中心頁面，對象視圖默認顯示的是高級對象視圖，即能夠看到所有系統和所有數據庫，如果看不到，點擊“工具”--“定制控制中心”，即可根據自己的要求顯示特定的控件（個人一般只用所有系統和所有數據庫這兩個，看各自的習慣了。）。
?。?）在“所有數據庫”的菜單中選擇“創建新的數據庫”，系統默認情況下會創建帶有自動維護功能的數據庫，如果不需要，即可右鍵“所有數據庫”，創建標準的DB2數據庫。輸入數據庫名稱，按照提示一步步創建即可。注：DB2的數據庫名稱最長為8個字符。
?。?）創建數據庫大約需要一分鐘，創建成功后可以在所有數據庫中查看。（選擇該數據庫，右鍵“啟動”，新建的數據庫一般不需要，如果是系統關機后，打開控制中心后要啟動該DB，否則該DB的其他功能不能使用。SQL命令是db2start）為了測試數據庫是否正常，可以用db2admin嘗試鏈接，鏈接方法前一篇已經介紹，這里不羅嗦了。
?。?）新建數據庫時，系統會默認創建常規、用戶的表空間，如果覺得這不夠，選擇表空間創建新的表空間即可，方法同數據庫類似，圖形操作一步步走下去就行了（在“類型”中選擇表空間類型）。
?。?）接下來是創建用戶，使用DB2記住一點，DB2的用戶即系統用戶，這一點和Oracle是有區別的。所以在創建DB2用戶前先創建對應的系統用戶（“我的電腦”--“管理”），刪除時只需刪掉系統用戶即可。創建系統用戶成功后，右鍵某個數據庫，選擇“權限”，添加用戶，從系統用戶中選擇某個用戶，授予其權限，所有的權限都羅列在下面的顯示框中，授予完成了確定即可。
圖2、添加用戶和授權頁面
（7）DB2默認的端口號是50000，如果端口號沖突了，可以選擇修改，修改的地方如下圖所示：
圖3、端口修改1
圖4、端口修改2
至此需要準備的環境工作（數據庫名稱、端口、用戶名和密碼）均已準備完成。
二、小提示：
在日常測試中我們經常會碰到SQL異常，又沒有足夠的信息幫助我們定位到底數據庫出了什么問題，去檢索IBM的文檔有點繁瑣，教一個小方法：
在擁有已經啟動好DB2服務的機器上點擊“開始”選擇“運行”，輸入“db2cmd”，確定后在cmd的窗口中輸入db2，看到db2=>時輸入？ SQLSTATE（這個值是SQL異常中SQLSTATE的那個值），即可快速查看是什么問題了。
三、DB2完全卸載方式：
如果我們想卸載某一款DB2產品，又怕會有殘留，影響后續安裝，那我們可以找到DB2的安裝程序，cmd下運行與setup.exe同級的db2unins.bat，加參數-f（所有DB2產品） -y（忽略確認）即可。其他參數可以通過幫助查看。
先提一個小學時候語文老師問過的一個問題：戰爭、戰役、戰斗三個詞語之間是什么關系？
之前我寫過刻苦學習之顛倒黑白和刻苦學習之自虐，表明關于什么時候學習如何學習，在5W1H（where when what why who how）的概念中其實我只說出了when和how并沒有說出其他的東西，當然該學習的人是你自己，那就是who，今天最后的一部分我們就來說說where what和why。
1、把所有的憑什么都變成為什么
很多人在工作上十分愛說憑什么，“憑什么他比我的工資高”“憑什么我要忙死了他還在那里閑著”“憑什么我要比他承擔更多的責任”“憑什么升職是他不是我”。是啊，大家想一想憑什么，當我們真的靜下心來想憑什么的時候，其實我們已經是在想為什么了。搞計算機的我們都要明白，有因才有果，所以我們只要追查出來原因，不久可以解決了嗎。當然有些情況是“他”是某某領導的“某某”，那么我們就不要再眼氣了，他是領導的“某某”，那即是領導讓他不上班在家還給他錢也是領導高興，現在領導給他錢他還來上班了，領導也就更滿足了，我們還有什么可挑剔的呢？另外還有一種情況，就是他什么都不會，領導就什么都不讓他干，而采用看起來沒問題實際問題大大的方式“能者多勞”。不要生氣，至少你在勞動就說明你是能者，如果你還是不滿意，把那些不勞動的也培養成能者吧。什么？你說這樣會加大競爭？那就沒有辦法了，如果你有這種想法，那你就只能做那個孤獨而多勞的能者了。
而實際上，在公司里最多的一種情況是你并不是能者，而他是能者，他可以隨意的做一件事情得到領導的滿意，他可以隨意的說一句話提一個意見讓領導給你多加若干的工作。那么我們還要說憑什么嗎？不要再說了，趕緊行動起來讓自己變成一個能者吧。當有一天你的能力和他一樣高的時候，你就可以隨意的去做了。當然這里涉及到的第一件事就是如何快速的追趕上他，其實很簡單，你無法變成一個全能的高手，但你至少變成一個學習的高手。如果以上所有的你都做不到，或者不符合你的要求，那只能說你選錯了where，趕緊換個地方吧。你說你換地方沒人會要你？那就對不起了，你一定是傳說中的“怨婦”，無能而把所有的問題歸咎于蒼天。
2、審時度勢 適應環境
任何人，無論有多高，都不可能在新進入一個環境的時候就成為高手，那么我們如何做呢？就像我剛才說的，至少你要表現出你的學習能力，換句話說就是思考能力。如果在接受一個新事物的時候你比其他人都快，那么你就會成為眾新手中的佼佼者，可能會享受到和老同志們相同的待遇，甚至有些更有挑戰性的東西會交給你而不是交給一些老頑固的。如果想接受新事物比別人快，就要在新事物來的時候更多的去學習更多的去思考，即使這件事物在你的人生中可能是唯一的一次，那也不要說我以后用不到我不學，因為這是給你的一次嶄露頭角的機會。說兩個我曾經做過的事情：
我剛剛進入測試行業測試的第一個軟件是一個累死飛鴿一樣的局域網即時通信類的軟件，功能點有幾十個，有十幾頁的測試用例，每周出兩個版本，我們幾個人的任務就是在新版本出來的時候重新執行一下所有的用例。因為多次重復，大家都不再看測試用例而是直接執行，這樣做雖然很快，但往往是會露掉幾個沒有測試。在幾次重復之后，我找一個空閑時間寫了一個功能點列表，只有一頁紙，然后發給大家，從這開始，大家不在看測試用例，而在測試過程中直接看這個測試點列表來檢查自己是否有漏掉測試用例。也是從那一天開始，那個項目的負責人把統計和整理大家測試結果的任務交給我，于是我有幸可以縱觀所有人的測試bug列表，從中吸取別人的長處補充自己的測試遺漏。也成為項目結束前測試人員中最重要的一位。
我曾經做過一次掃描槍的選型測試（通過測試對比若干產品的優劣選擇其中更好的），就是那個在超市掃描標簽在屏幕上顯示一串串讓你心驚肉跳的數字的東西。接觸這個項目的時候，包括項目經理在內任何人都沒有接觸過這個東西，更別說在幾十個樣品中通過測試和得到的數據有力的說明哪一個更好。幾個同時進入項目的人在相關廠家的介紹下開始制定測試標準，但是廠家往往會在告訴我們一些東西的時候回避他們產品的不利部分，所以我們收集了很多廠家的意見合并在一起，但仍然感覺少了些什么。就在這個時候，我拿出過去看雜志中對筆記本的評測文章，自習的分析，說出除了掃描的性能外還有很說使用舒適性上的區別，并且列出超過十條這方面的對比條件。另外，在條碼掃描糾錯一項上，大家對有問題條碼一直無法定位，我便在生活中觀察到底條碼會受到什么方面的破壞，在若干超市的觀察之后，我總結出半透明覆蓋、磨損、劃痕、撕裂、不平整等幾種并且更新到測試規范中。自此，項目經理看到了我在這方面的開拓精神，把制定此次測試規范的任務交給我，我也在測試過程中不停的改進測試的過程，最終成為這次測試的規范制定者和技術顧問，而眾多同時參與測試的人都只能遵循我所制定的測試方法進行每天不停的掃描和數據記錄。評良心說，我這輩子不太可能再接觸這方面的測試了，我自己也不想再做。不過我在這次測試中顯出了我的能力，領導從這開始盡量把有挑戰性的任務交給我來做，我也有更多的時間來研究和學習新的東西，而這大多是我本專業的東西，學完了可以受用一生。
不知道大家看到上面兩個例子是什么感覺，雖然在一開始的時候看起來比別人要累一些，但是逐漸的越來越輕松。更有效果的是，如果這樣的事情進行幾次，領導自然會在有領導職位空缺的時候把你考慮進去（雖然現在我還沒有成為領導，呵呵）。
3、選擇道路適應未來
無論工作有多忙，在你工作經驗逐漸增多的過程中都會慢慢的有所感覺，知道自己未來的大致方向，至少知道自己的職業生涯是屬于哪一個行業。那么，我們是否應該在知道這些事情之后把它明確，做好各種準備，在機會到來的時候大展身手一展宏圖呢？我們經常聽到有人說機會是留給有準備的人的，事實也是這樣。其實很多機會在你面前，你未必看不到，就是抓不住，原因很簡單，就是你沒有做好足夠的準備。不要說你沒有看到機會，任何公司的任何一次招聘對你來說都是一次機會，你沒有去成，就是因為你的能力還不夠，不要說什么經驗之類的，如果你能力非常高，經驗的門檻就一定會降低的，同樣的能力，如果是你你是否會選擇更年輕一點的呢。那么我們在選擇好道路的時候，就要提前開始走這條路了，雖然你的工作和這些不相干，你也要開始學習，積累這方面的知識，等有一天機會來的時候，你至少比別人懂得多一點點，就是這一點點決定了你得到了這個機會，而別人沒有得到。也許你還不知道你的未來是什么，也許你還不知道你所選擇的道路到底應該學什么，其實這很簡單，只要一小段時間，你廣博的學一下各個學科的基礎，你就會知道你適合干什么，喜歡干什么。就好比一桌豐盛的菜肴，你不知道哪一個適合你的口味，最好的辦法就是都吃一口，你就知道你喜歡吃哪一個了。到這個時候你知道了你想走的路，首先要做的一件事就是把這條路的路障搞清楚。假設我們搞測試的人選擇的性能測試，首先要知道最廣泛的工具是LR，也是入門基礎，那就要開始學習，而這個學科更重要的是執行和分析，所以你要懂些代碼和架構的知識，這些代碼和架構又建立在一個硬件和軟件的環境上，所以你還要懂些硬件和操作系統的知識，性能通常是網絡軟件，所以你還要知道些網絡的東西。好了，到此你的知識結構已經確定。至于這些知識應該哪個輕哪個重，學到什么程度，就留給你們自己去想吧。
4、深挖洞廣積糧（書海戰術）
很多人即使知道自己的路在哪里，卻不知道自己應該怎么走，我學習一段時間最大的感受就是大家通常在說我要學某某的時候卻不知道從何下手。具體來說，就是不知道先學什么后學什么，需要看什么書。其實問題很簡單，要么去問這行業的高手，要么就行動起來，去想是一定不會想出來的。行動的方法就是把網上或者書店了解到的這個行業的書多買幾本回來，從自己認為寫的比較簡單的那一本開始（我通常認為是否寫的比較簡單的辦法就是看薄厚和是否多圖），迅速的去讀，不需要精，你現在要做的是了解這個行業，等這基本書讀完的時候，你應該就知道自己應該做些什么了。所謂深挖洞，就是把這些知識的儲存做好，越多越好，廣積糧就是要把所有的儲存的知識都快速吸收，不論效果先瀏覽一遍再說。開始可能會很迷茫，一段時間之后這些看似散亂的東西就是逐漸在你心里結成一張知識網，雖然這張網不是那么鮮明，不是那么清晰，但是你一定會找到屬于你的那個脈絡。有人說這樣很浪費時間，可能學到了很多我們一輩子都用不到的東西，那好吧，你還可以賭一下，試試專注。
5、專注
所謂專注，其實十分簡單，就是想盡辦法得到各方的支持，包括身邊的高手（公司的厚著臉皮去問），網絡上的高手（去查），專業書的作者（找到他們的郵箱給他們發信），得到一個最集中的判斷哪本書最好，然后拼盡全力去鉆研那唯一的一本書，一遍一遍的讀，不厭其煩的讀，讀上十遍，想不成為專家就難。其實很多東西很好問道的，比如像學Java，問他們你得到的答案一定是《Java編程思想》問學MFC的一定回答《深入淺出MFC》問搞軟件項目管理的當然要看《人月神話》。其實就是這樣簡單，不要費那么多腦子去選擇，不用自己去梳理知識脈絡，只要你按照別人告訴你的答案，按照書中的步驟一步一步去走就可以了。不過提醒大家，這種方式有至少兩個缺點。第一就是學習的東西比較單一，無論你看哪本技術的書，如果它寫的深，必然涉及到的面不夠廣，任何一個行業就職的人也不可能就靠一個方面的知識就能夠打拼出來，更何況現在企業大多需要多面手，逐漸成長之后還是要把面鋪的廣些。另一個就是，開始就去研究這些書因為基礎不牢，書寫的又很深，所以可能會很困難，要吃很多苦頭，甚至有些時候會有些迷茫，容易放棄，需要大家有很強的毅力去堅持。也許大家也感覺到了，專注和書海戰術的區別就是由點到面和由面到點，如何選擇就你自己來考慮吧。
回到開始的問題，戰爭、戰斗、戰役到底是什么關系，這個簡單的語文問題大家其實都知道答案。但是我們到底是應該研究戰爭，還是應該研究戰役，或者戰斗，研究哪場戰役，哪場戰斗呢？沒有確定的答案，要在具體的時間，具體的情景下具體的人根據自己的個性去判斷。
最后聲明一下，我寫的東西未必我自己全部做到，但是至少我做到了70%，即使這樣我也認為我在我的環境中做的還是很優秀的，至少我沒有奮斗上的遺憾。希望大家也不要給自己最應該輝煌最應該奔跑的時刻留下什么遺憾。
DevSuite系統中的文檔管理工具叫做KnowledgeWise，在以“知識為核心” 的理念中屬于核心地位，因為軟件開發過程中其實每個階段都需要接觸文檔的，從需求文檔到設計文檔到開發文檔到測試文檔再到發布文檔維護文檔，文檔自始至終一直是需要的，而且同一個文檔在整個過程可能是不斷發生更改的，所以通過KnowledgeWise跟蹤到每個更改對于開發過程來說或是及其重要的。
在KnowledgeWise中，文檔通過條目（Item）的方式來記錄的，也就是一個文檔對應一個條目，每個條目首先會有標題，描述，負責人，附件等字段組成，這些字段是自定義，可以根據你的需要而添加，這是所謂的基本屬性。然后條目還有一些高級屬性，比如權限控制，流程控制，版本控制，歷史跟蹤記錄等等，下面我就結合我們公司的實際流程來介紹一下這個系統。
1、首先對于那些制度類的，合同類的文檔，還有培訓類的文檔，我就不詳細介紹了，因為這些文檔不需要所有人都需要看到的，甚至有些需要保密的，更加不能讓很多人看到了。通過KnowledgeWise可以保存到只有相關人員才能看到的地方。KnowledgeWise可以為每個人針對每個文件，每個文件夾設置不同的權限，比如只讀，可以編輯，可刪除，可創建，當然還有不可見。所以你想設置如何復雜的權限組合都是沒問題的。（權限管理）
下面的兩個圖中，可以看到，我們可以為文件夾與文件設置不同的權限，而且是可以為不同的人設置不同的權限的，也就意味著，就是兩個人都是經理，我也可以讓一個文件只讓其中一個人看到。
2、然后就是一些設計文檔、開發文檔或者是FAQ之類的，這些文檔在實際過程中總是會經過很多流程最終產生一個成品，拿設計文檔來說吧，一個設計文檔從最初有意向，到最后成型，可能分為以下幾個部分：草稿—>初級審核—>繼續修改—>再次審核—>最后修改—>最后審核—>同意，這么幾個過程，而且每個過程中，負責處理的人也不一定是一樣的，草稿可能是有普通設計人員處理的，初級審核應該是設計組長處理，最后審核可能是設計主管處理，所以我們就需要設置嚴格的工作流程和相應的權限，流程剛才已經說過了，權限的話，意思是說，比如這個文檔在“初級審核”階段，必須設計組長才有權限去把這個文檔改變到繼續修改狀態，其他人沒有這個權限，甚至其他根本就沒法看到這個狀態下的那個文檔，這樣就確保是設計組長審核過才去繼續修改的，杜絕了有些人想盡快通過這個文檔而直接跳過流程改狀態了（當然，在KnowledgeWise中經過自定義設置是可以跳過流程改狀態的，當然正常情況下，這個必須是有一定權限的人才能做的，比如主管，經理等）（流程管理）
下面兩個圖是一個典型的文檔的流程的，第一個圖是在系統中自定義設置一個流程，第二個圖是系統客戶端的實際使用情況，可以看到，一個文檔從新建到最終成型在正常情況必須通過每個狀態的負責人的處理后，走完這個流程，這樣子基本上能夠保證一個文檔的質量。在系統中，每個能進入的系統的人，只要一進系統就可以看到自己需要處理的不同狀態的文檔任務，包括寫文檔、修改文檔和審核文檔。
3、軟件公司的做設計的人應該知道，對于一個設計文檔而言，會不斷地經過修改，即使是最后定稿了以后，可能一個新的改動過來，又得改，但是經常地我們也碰到了一種問題，就是我改完了，但是發現改錯了，想看看原來是怎么樣了，或者客戶不滿意想改回一個禮拜之前那個設計，總之就是我想還能看到這個文檔每次改動時內容，然后進行一些回滾操作，或者有時候需要對兩個不同版本的內容進行比較，看看到底做了哪些改動，改動前是什么，改動后是什么。（變更管理，版本管理）
在KnowledgeWise中，對一個文檔條目，每一次操作都能用快照方式記錄一個版本，所謂快照方式，就是類似一個拍照功能，把該版本文檔的相關內容拍下來，以后只能看，不能改。當然，你可以設置不讓每次修改都保存版本，只修改一些關鍵地方的地方才去保存一個版本，不然版本太多，以后比照起來也挺累人的。
對于保存下來的版本，主要有三個用處，
第一個當然是去看嘮，可以看看在過去某個時段，這個文檔是啥內容；
第二個內容就是回滾作用，就是說如果一旦我這個文檔修改了一下，覺得不對，想恢復到修改前的樣子，就可以回滾一下，當然你是可以回滾到任何已經保存下來的版本里的，那么那個版本里的內容將會覆蓋當前內容，所以一般情況下如果想回滾的話，你可以先手動做個版本保存，這個在KnowledgeWise中是允許的，而且即使做了回滾，所有的已經保存的版本還是不會受影響的。
第三個作用就是兩個版本間的相互對比，有時候我們作了修改后，想對比一下兩個版本之間到底有什么不一致，究竟改了多少地方，一旦我們用了對比功能以后，就可以把這個文檔的所有字段在不同版本間進行一一對比，有修改的地方會被自動標記，例如這個版本比那個版本就是刪除了一段話，這樣子的話，對比的時候，被刪除的這段話就會自動加上顏色，并且會加上一個刪除的線，一目了然。（關于對比這個功能，有些版本控制管理軟件其實做得更好，類似Subversion，所以KnowledgeWise也提供了跟Subversion集成的效果，有任何文件作為附件放到一個文檔里去的時候，可以同時被自動提交到Subversion中，這樣子，就可以對附件也進行對比了）
下面的圖就是版本保存的地方。
4、類似FAQ這些文檔，其實最終我們做完后是給我們的客戶用的，也就是給他們看的，作為幫助文檔的方式，所以放在系統中的話，就不太適合他們去看，可看性不好，所以KnowledgeWise提供了一種Wiki功能，可以將指定的文檔用Wiki方式給用戶看，下面就是一個典型的FAQ在線幫助的截圖。
5、另外的話，KnowledgeWise還支持直接由Word或者PDF文檔中直接把內容導入到系統中作為一個條目，甚至可以把Word/PDF中分段的內容導成幾個相關聯的條目，當然也支持導出功能和報表功能了。
6、KnowledgeWise的文檔管理支持服務器-瀏覽器形式的訪問，所以只要你能訪問你們公司的網頁，你就能訪問到你想要的文檔，局域網與廣域網訪問起來沒有任何區別。
總的來說，KnowledgeWise是一個非常棒的文檔管理系統，完全滿足了我們公司的要求，甚至超出了不少期待，因為它能跟我們買的其他TechExcel產品做無縫的集成，也就是說一個文檔我可以在不同產品中都能看到，如果有更新我也能一下子看到，對于我們公司的軟件開發過程是相當有幫助的。