今天有11度呢，中午的時候邊出太陽邊下雪
真是厲害
大概是你對我的祝福吧
不管是有人帶還是沒有人帶，做技術10年才能算入門，知道方向了，要想做出驚天動地的事情來至少需要15-20年。 計算機技術難度不是太大，主要是多，並且相互聯繫。沒有長時間的摸索是分不清東南西北的，再聰明再厲害，還是不能創新，幹不出大事
題目 Boom there have a game. 雙擊運行，開始界面 回車，輸入md5值 上去查 https://www.cmd5.com/ en5oy 到了下一關 三元一次方程 求解x，y，z 我自己拿草稿紙手解。。。加
參考文檔：http://manpages.ubuntu.com/manpages/wily/man1/get-edid.1.html 原文： Name Synopsis Description Author See Also wily (
問：說到文檔，東西再好，包裝不行，就上不了檔次。這個我很理解。過去有一個小公司想代理我們公司的軟件，但我們連演示版都沒有，最後告吹。可是寫文檔是件很矛盾的事情，因爲最清楚功能的人當然是開發部的人，但是我們整天在編碼哪有時間再去寫文檔，而且
問：我過去在另一家公司，從調研、設計數據庫設計功能、開發、測試、寫文檔、實施推動上線協調各方、培訓、修改客戶需求、接聽客戶電話都是開發部一夥人自己做。 現在這家公司還好點，有實施部，有客服部。測試就是他們在做。但也都是糊弄事，他們又不
問：產品出來了，確實需要到客戶處真正運行了才能知道這個產品到底實用不實用，那選擇客戶上有什麼技巧沒有？ 答：首先，選擇什麼客戶。一定要選擇一個匹配你的產品的客戶。因爲這是你最大份額的客戶，也是以後最容易擴展的客戶類型。當然你的產品首先
問：產品穩定，產品也有亮點，培訓也上檔次，文檔也齊全。確實，客服這回清閒了。那客服的作用是什麼呢？ 答：客服當然有用了。 首先，對於上一講的需求，計算機室人員要交給客服部而不是直接交給開發部。客服部會首先把需求記錄進“需求與BUG
問：我們現在可以開始編碼了，這是我們最擅長的事情，那麼在這個環節我們該注意些什麼呢？ 答：在《業務開發小組》一節中我就講到，業務組長在設計功能時就要思考這個功能是不是一個其他小組也要用的功能。 這樣思考帶來的好處就是： 1大家在協
問：實施時候，需求也是拖延我們實施很多時間的重要因素之一。客戶遲遲不上線，不上線我們就無法驗收。那我們該怎麼辦呢？ 答：首先，你們要有一些策略的調整。你們是以什麼爲驗收標準。以客戶上線爲驗收標準是不科學的，因爲什麼算上線定論不一。我們
軟件測試知識帖(41-60) 第41帖【2004－6－27】：測試自動化的限制 測試自動化可以帶來非常明顯的收益，但也有其限制，主要有： 1.不能取代手工測試 2.手工測試比自動測試發現的缺陷更多 3.對測試質量的依賴性
軟件測試知識帖(81-100) 第81帖【2004－8－12】：新的可測試性設計思想 隨着科技與經濟的發展，爲提高產品的質量和競爭力，傳統的縱向設計流程必然讓位於“並行工程”設計。在並行工程設計環境下，可測試性技術的內涵與設計
軟件測試知識帖(101-114) 第101帖【2004－9－10】：USE CASE測試 USE CASE 是UML的核心，貫穿了RUP開發方法的整個過程，實際上RUP講的就是一種USE CASE 驅動的開發方法。我們可以使用
軟件測試知識帖(1-20) 來源：測試時代(www.testage.net) 第1帖【2004－5－10】：軟件測試的理想模式是什麼？ Brian Marick：我不認爲存在什麼理想模式。我覺得讓開發人員承擔某些測試也許會更
13 小時前 JavaEye管理員 發給 我 的消息正文:hax，你好!發表到JavaEye博客頻道首頁的文章應該是原創性質的、言之有物的文章，並且不
環境ubuntu 11.04 0、參考文章 http://blog.21ic.com/user1/6297/archives/2010/69706.html http://hi.baidu.com/5924431/blog/item/1
