之前不知道做了什么，搞得Flex Development里面的AS項目無法自動檢錯，寫了錯誤的代碼它也不會檢錯，后來還一度打算換FDT呢，不過那個太卡了，沒法用，只能硬著頭皮解決Eclipse問題。

重新弄了個Eclipse，然后擴展了FB插件，問題依舊，在FB打開也是，初步判定是工程的設置有問題。

進入項目，右鍵屬性設置，建立Main文件夾，并且設置Main函數，也就是項目啟動后第一個運行的程序，（在ActionScript Applications 和ActionScript Build Path都要設置），另外還可以設置Run，那樣當你點Run時，就會自動編譯生成swf了，太強大了。

我使用svn一直很順利，今天在改了兩個地方之后，提交時輸入了兩句話(只有兩行)做為注釋，但是確定提交時失敗，說“Cannot accept non-LF line endings in 'svn:log' property”，中文翻譯就是標題所示。

我暈，以前都是很正常的，沒有碰到過這種情況，好像注釋多少沒有什么關系的

把第二行的結尾處增加了一個回車，這樣有三行，第三行是空的，但提交還是一樣的錯誤，

然后只好上網上查了一下，很多是英文的，找了三篇文章，其中一篇中文的解決了：每一行以空格結尾

我刪除第三個空行，在前兩行的后面都增加了一個空格，然后就提交成功了

這篇文章上還有人說需要以標點符號做為結尾，但我試了，以“.”結尾還是無法提交

終于發現，很“牛”的軟件，也有這么傻瓜式的bug存在

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/jszj/archive/2009/05/25/4214626.aspx

職位描述：
你將出任團隊的ScrumMaster角色，直接與產品及研發團隊工作，計劃并保證在每一個開發沖刺中提交高商業價值的產品功能；
推動每日例會，解決團隊碰到的障礙，跟蹤團隊進度，持續溝通尋求產品和研發雙贏的解決方案；
你還需要擔任Srum導師的角色，培養更多能推動Scrum方法的人才。

職位要求：
計算機相關本科或碩士學位；
5年研發項目經驗，3年項目管理或QA經驗；
有Scrum開發項目實戰經驗，擔任過Scrum Master角色；
熟悉feature驅動開發模式，了解配置管理，持續集成；
出色的人際交往能力，優秀的計劃及溝通技巧；
有直接與產品部門及技術團隊合作的經驗；
熟悉至少一種開發語言和一種腳本語言。

Scrum Master

學歷要求：本科|工作經驗：3-5年|工作地點：上海  |月薪：1000-50000元/月|發布日期：2009-12-10

Job Description - Keep the team focused on delivering highest business value - Strong emphasis on teamwork and close collaboration across all roles and functions - Work with other Scrum Masters to coordinate and mitigate dependencies across teams - Ensure that projects have a clearly defined release scope and meet overall objectives, standards, quality and user needs - Must possess personal leadership skills, initiative, and strong attention to detail - Manage multiple projects simultaneously and work with outside vendors - Work with team, cross-team resources, and stakeholders to mitigate risks and remove barriers - Synchronize with non-technical teams to deliver product releases smoothly - Coordinate system and project dependencies for releases - Engage, motivate and focus the team to stay on task and on target - Serve as a change agent to coach and mentor team on Scrum practices - Guide the Product Owner on how to maximize ROI and meet their objectives through Scrum - Provide visibility to the organization regarding team's progress and release schedules Required Experience - Proven experience releasing software products to market successfully - Bachelor's Degree or equivalent experience and approximately 4-6 years related experience - Excellent leadership and interpersonal skills to motivate the team and interact with the various stakeholders - Ability to understand technical subjects - Strong written and verbal communication skills - 4-5 years project management experience - 2-3 years Scrum experience Highly Desirable - Experience with transitioning an organization to Scrum - Experience leading teams in the development of .Net-based software development - Experience with Microsoft Team Foundation Server - Scrum Master certification

摘要：產品負責人的詳細職責包括三個主要領域：客戶需求，項目成功和團隊合作。在Scrum中，產品負責人要與客戶溝通需求并理解這些需求；保證項目成功是產品負責人的第二個職責；最后一條也很重要：產品負責人要與整個團隊進行溝通協作，在整個過程中與利益相關者保持一致。

Scrum中，產品負責人這個角色具有很大的影響力，但要想運用得當，可沒那么輕而易舉：如能成功應用，就可以在客戶/產品管理和開發者之間建立起全新而融洽的關系，企業也將因此而受益，甚至有可能增加競爭優勢。不過天下沒有免費的午餐：為了發揮其作用，組織要經常要做出有針對性的調整。這篇文章揭示了成功發揮產品負責人角色作用的奧秘。閱讀之后，讀者就可以明白：成功的產品負責人需要具備哪些素質。

強力膠

在Scrum中，產品負責人扮演著重要的角色。它根本不是為老職位設置的新名稱，而是重新定義了業務和開發/IT之間的關系。需求的處理方式也在改變，不必再像過去那樣，在項目一開始就必須完整描述，凍結之后再轉交給開發團隊。將管理項目的責任單獨指派給項目經理，整個過程中沒有客戶代表的參與，這種項目管理的方式也變了。取而代之的是，產品負責人通過溝通了解客戶的需求，指導產品的發布，并根據眼前的實際情況，不斷在團隊和項目干系人之間協調。可以這樣說，產品負責人扮演了粘合劑的角色，他需要幫助最終客戶、產品管理負責人、開發人員和項目干系人達成一致，確保大家都在朝著同一個方向前進。

這個角色通常是由客戶或者產品經理承擔的，所以業務層面也要開始了解Scrum，并做一些必要的變化與之相適應。雖然實際操作上有不少難度，但產生的結果物超所值。不僅能在業務人員和開發/IT人員之間建立起更融洽的關系，而且能給企業增加競爭優勢：用戶需求得到順暢溝通；有專人負責版本目標的定義和發布；決策流程得以提速；誤會和工作方向不一致的情況也得以避免。

工作描述

產品負責人的詳細職責包括三個主要領域：客戶需求，項目成功和團隊合作。

在Scrum中，產品負責人要與客戶溝通需求并理解這些需求。不妨將產品負責人想象成企業家：他們從業務價值的角度來制定軟件產品的未來發展規劃，并與別人溝通自己的想法。產品負責人要填寫產品 backlog，并根據實際情況隨時修改這些內容：可能要增加新需求，修改已有需求，這通常都是實時性的，而且這些修改都要在下一次sprint 計劃會議之前完成。另外，產品負責人要對產品backlog上的條目排定優先級，確保團隊總是在處理最重要的需求。

保證項目成功是產品負責人的第二個職責。這包括滿足項目目標以及財務目標，如投資回報率（ROI）。產品負責人決定功能、發布時間，從使客戶滿意度最高和獲得最高ROI的角度出發安排預算。產品負責人還要創建并更新發布計劃及發布報告。

最后一條也很重要：產品負責人要與整個團隊進行溝通協作，在整個過程中與利益相關者保持一致。產品負責人要和團隊一起確認詳細的需求。在產生疑問的時候，產品負責人解釋需求，并根據當初就“完成”標準達成的共識對工作結果進行評估。最后，產品負責人要針對sprint計劃會議做準備工作。在會前需要逐步分解需求，讓會議可以順利進行。

擔當產品負責人的角色應該是全職工作，特別是涉及到需要大量創新或者很復雜的項目。根據項目的特性和規模，這項工作可以由最終客戶、產品經理、市場人員或者客戶來擔任。

常見陷阱

老實說：產品負責人這個角色可不是那么好做的。這些年來，我見過許多產品負責人所犯的常見錯誤。下面這些是我想告訴大家的。

有些組織認為僅由一個人來擔任這個職位很困難。為解決這個問題，他們會讓多個人分擔產品負責人的角色，例如產品經理負責用戶需求，ScrumMaster負責項目成功和團隊協作。我把這個問題稱作“虛擬產品負責人綜合癥”。一旦陷入其中，公司將失去產品負責人所帶來的很多好處，而且還喪失了本可以因此變得更好的機會。多人執行產品負責人的職責，只適用于多個團隊參與同一個項目的狀況。在這種情況下，我愿意與一組產品負責人工作，而且其中有一位負責整個項目（有時此人被稱為產品總負責人）。

讓IT人員或者程序員擔任產品負責人，這是另外一個常見的陷阱。這意味著產品管理人員或者最終客戶不愿意進行改變，不想擔當起產品負責人的職責。“IT 產品負責人” 僅僅是技術和業務的中間人。這個角色將不再具備原本的影響力，也沒有人來理解和溝通客戶需求。業務人員和開發/IT人員不再為了合作而進行必要的改變，關系無法得到改善。跟以前一樣，業務人員將需求交給開發部門之后就不再過問。（話雖這么說，也有特殊情況：如果是涉及多個團隊的項目，其中有一個組件開發團隊，那么讓架構師充當這個團隊的產品負責人，盯著他們的工作，這還是挺不錯的。）

最后的問題是“蹦極產品負責人”（當然，這個名字來自Dilbert漫畫）：一個幾乎沒什么作用的產品負責人，只參加sprint計劃會議和復查會議。這類型的產品負責人很難主動控制和指導項目。許多沒有答案的問題只能通過ScrumMaster簡單的猜想或推測來回答。另外一些產品負責人還會妨礙項目取得進展。無論是什么原因，工作過度還是有其他更重要的工作——不能正常發揮作用的產品負責人會對產品發布起負面作用。

成功公式

如何能夠避免上述陷阱，并成功發揮產品負責人的作用？我發現了三個關鍵因素：

1. 產品負責人必須得到授權
2. 擔當該角色的那個人必須有足夠的時間完成工作
3. 產品負責人必須稱職

過去的經驗證明，這幾個因素非常關鍵。我發現：一個被授權的、能夠全心投入的、稱職的產品負責人，和Scrum項目的健康和成功之間，有著密不可分的關系。

“授權” 的意思是指：產品負責人有權力做決定，能為決定所產生的結果負責。這要求產品負責人能夠快速做出相關決定，不需每次都要得到管理層的批準。我常常遇到這樣一些公司，他們低估產品負責人的重要性，因此而使得產品負責人得不到足夠的授權。如果產品負責人被任命領導重要的項目，那么高層管理人員應該為其提供直接支持。另外，產品負責人應該積極參與到發布目標的設定中，這樣他就會完全負起達成目標的責任。

“缺乏參與” 最后將影響到項目的產出效率。必要的準備工作無法完成，決策延遲。正如前面提到過的，“蹦極產品負責人”只參加sprint計劃會議和復查會議，因此很難迅速、全面地解決項目中出現的問題。他們無法與團隊形成持續的協作，導致自己控制和指導項目的能力被削弱。

“稱職”包括兩個意思：完全了解客戶的需求，具備敏捷和Scrum的實用知識。第二點包括能夠實行相關的實踐，例如準確填寫和修改產品的backlog，或以用戶故事的形式描述需求。在Scrum里，產品負責人需要接受適當的培訓，這樣他們才能很好地完成工作，就像ScrumMaster一樣。一般說來，將 “Scrum認證產品負責人™”課程和上崗培訓/指導結合起來，會產生最好的效果。

為了讓產品負責人順利發揮作用，你可以試試下面的方法：保證管理層都了解這個角色的重要性，并小心選擇產品負責人的人選。此外，還可以讓這個人投入盡量多的時間以勝任該職位，并遠離其它工作的干擾。最后，要從長遠發展的角度出發：培養產品負責人——要注意培養現有的員工，讓他們準備好擔任產品負責人的角色。這要求建立起內部的培訓和指導能力。

陳年舊聞

產品負責人能夠為組織帶來很好的作用，當想做好卻不容易。要培養員工成為好的產品負責人同樣面臨不少困難。有意思的是，豐田、本田以及其他一些精益企業，在很長時間內成功實施了產品負責人的機制。事實上，這種機制在豐田已經實施了差不多一個世紀。豐田公司的產品負責人被稱作“首席工程師”，只有為人稱道的資深工程師才能擔任這個職位。首席工程師承擔了產品負責人職責中的一大部分，同時還要承擔首席架構師在開發項目中的工作。雖然首席工程師的工作要比 Scrum中產品負責人更有難度，豐田仍然成功實施了這個角色，并讓它成為了強大的精益系統中的基石。豐田的例子說明，如果企業愿意作出必要的改變，產品負責人能夠增強企業的競爭優勢。

總結

毫無疑問：要發揮產品負責人角色的作用非常困難，但是適當的應用是成功Scrum的必要因素。削弱這個角色的權力也許可以讓其更容易發揮作用，可是帶來的好處也因此而減少了，所以要抵抗改造這個角色的誘惑。相反，要利用發現的問題和障礙，使之驅動組織進行必要的調整，這將對整個企業起到改善作用。企業可以利用這個角色來增強競爭優勢。做出必要的改變是很艱難的工作，也需要花費一些時間。不幸的是，我沒有發現Scrum有什么神奇的魔力可以讓變化輕而易舉地發生。如果我找到了，一定會讓你們知道。我保證。

           討論Web開發技術的歷史，當然要先說說Web的起源。眾所周知，Web這個Internet上最熱門的應用架構是由Tim Berners-Lee發明的。Web的前身是1980年Tim Berners-Lee負責的Enquire（Enquire Within Upon Everything的簡稱）項目。1990年11月，第一個Web服務器nxoc01.cern.ch開始運行，Tim Berners-Lee在自己編寫的圖形化Web瀏覽器"WorldWideWeb"上看到了最早的Web頁面。1991年，CERN（European Particle Physics Laboratory）正式發布了Web技術標準。目前，與Web相關的各種技術標準都由著名的W3C組織（World Wide Web Consortium）管理和維護。

　　 從技術層面看，Web架構的精華有三處：用超文本技術（HTML）實現信息與信息的連接；用統一資源定位技術（URI）實現全球信息的精確定位；用新的應用層協議（HTTP）實現分布式的信息共享。這三個特點無一不與信息的分發、獲取和利用有關。其實，Tim Berners-Lee早就明確無誤地告訴我們："Web是一個抽象的（假想的）信息空間。"也就是說，作為Internet上的一種應用架構，Web的首要任務就是向人們提供信息和信息服務。

　　 很可惜，在Web應用日新月異的今天，許多搞技術的人似乎已經忘記了Web架構的設計初衷。他們在自己開發的網站或Web應用中大肆堆砌各種所謂的"先進"技術，但最終用戶能夠在這些網站或應用中獲得的有價值信息卻寥寥無幾。這個問題絕不像評論者常說的"有路無車"或"信息匱乏"那么簡單。一個Web開發者倘若忘記了Web技術的最終目標是提供信息和信息服務，他的愚蠢程度就絲毫不亞于一個在足球場上只知道賣弄技巧，卻忘記了射門得分的大牌球星。從這個角度來說，評價一種Web開發技術優劣的標準只有一個，那就是看這種技術能否在最恰當的時間和最恰當的地點，以最恰當的方式，為最需要信息的人提供最恰當的信息服務。

　　客戶端技術的萌芽和演進

　　 Web是一種典型的分布式應用架構。Web應用中的每一次信息交換都要涉及到客戶端和服務端兩個層面。因此，Web開發技術大體上也可以被分為客戶端技術和服務端技術兩大類。我們先來談談客戶端技術的萌芽和演進過程。

　　 Web客戶端的主要任務是展現信息內容，而HTML語言則是信息展現的最有效載體之一。作為一種實用的超文本語言，HTML的歷史最早可以追溯到上世紀四十年代。1945年，Vannevar Bush在一篇文章中闡述了文本和文本之間通過超級鏈接相互關聯的思想，并在文中給出了一種能實現信息關聯的計算機Memex的設計方案。Doug Engelbart等人則在1960年前后，對信息關聯技術做了最早的實驗。與此同時，Ted Nelson正式將這種信息關聯技術命名為超文本（Hypertext）技術。1969年，IBM的Charles Goldfarb發明了可用于描述超文本信息的GML（Generalized Markup Language）語言。1978到1986年間，在ANSI等組織的努力下，GML語言進一步發展成為著名的SGML語言標準。當Tim Berners-Lee和他的同事們在1989年試圖創建一個基于超文本的分布式應用系統時，Tim Berners-Lee意識到，SGML是描述超文本信息的一個上佳方案，但美中不足的是，SGML過于復雜，不利于信息的傳遞和解析。于是，Tim Berners-Lee對SGML語言做了大刀闊斧的簡化和完善。1990年，第一個圖形化的Web瀏覽器"WorldWideWeb"終于可以使用一種為Web度身定制的語言--HTML來展現超文本信息了。

　　 最初的HTML語言只能在瀏覽器中展現靜態的文本或圖像信息，這滿足不了人們對信息豐富性和多樣性的強烈需求--這件事情最終的結果是，由靜態技術向動態技術的轉變成為了Web客戶端技術演進的永恒定律。

　 　能存儲、展現二維動畫的GIF圖像格式早在1989年就已發展成熟。Web出現后，GIF第一次為HTML頁面引入了動感元素。但更大的變革來源于1995年Java語言的問世。Java語言天生就具備的平臺無關的特點，讓人們一下子找到了在瀏覽器中開發動態應用的捷徑。1996年，著名的Netscape瀏覽器在其2.0版中增加了對JavaApplets和JavaScript的支持。Netscape的冤家對頭，Microsoft的IE 3.0也在這一年開始支持Java技術。現在，喜歡動畫、喜歡交互操作、喜歡客戶端應用的開發人員可以用Java或JavaScript語言隨心所欲地豐富HTML頁面的功能了。順便說一句，JavaScript語言在所有客戶端開發技術中占有非常獨特的地位：它是一種以腳本方式運行的，簡化了的Java語言，這也是腳本技術第一次在Web世界里嶄露頭角。為了用純Microsoft的技術與JavaScript抗衡，Microsoft還為1996年的IE 3.0設計了另一種后來也聲名顯赫的腳本語言--VBScript語言。

　 　真正讓HTML頁面又酷又炫、動感無限的是CSS（Cascading Style Sheets）和DHTML（Dynamic HTML）技術。1996年底，W3C提出了CSS的建議標準，同年，IE 3.0引入了對CSS的支持。CSS大大提高了開發者對信息展現格式的控制能力。1997年的Netscape 4.0不但支持CSS，而且增加了許多Netscape公司自定義的動態HTML標記，這些標記在CSS的基礎上，讓HTML頁面中的各種要素"活動"了起來。1997年，Microsoft發布了IE 4.0，并將動態HTML標記、CSS和動態對象模型（DHTML Object Model）發展成了一套完整、實用、高效的客戶端開發技術體系，Microsoft稱其為DHTML。同樣是實現HTML頁面的動態效果，DHTML技術無需啟動Java虛擬機或其他腳本環境，可以在瀏覽器的支持下，獲得更好的展現效果和更高的執行效率。今天，已經很少有哪個HTML頁面的開發者還會對CSS和DHTML技術視而不見了。

　 　為了在HTML頁面中實現音頻、視頻等更為復雜的多媒體應用，1996年的Netscape 2.0成功地引入了對QuickTime插件的支持，插件這種開發方式也迅速風靡了瀏覽器的世界。在Windows平臺上，Microsoft將客戶端應用集成的賭注押到了1990年代中期剛剛問世的COM和ActiveX身上。1996年，IE 3.0正式支持在HTML頁面中插入ActiveX控件的功能，這為其他廠商擴展Web客戶端的信息展現方式開辟了一條自由之路。1999年，Realplayer插件先后在Netscape和IE瀏覽器中取得了成功，與此同時，Microsoft自己的媒體播放插件Media Player也被預裝到了各種Windows版本之中。同樣值得紀念的還有Flash插件的橫空出世：1990年代初期，Jonathan Gay在FutureWave公司開發了一種名為Future Splash Animator的二維矢量動畫展示工具，1996年，Macromedia公司收購了FutureWave，并將Jonathan Gay的發明改名為我們熟悉的Flash。從此，Flash動畫成了Web開發者表現自我、展示個性的最佳方式。

　 　除了編寫HTML頁面之外，客戶端應用的開發者還可以利用一些成熟的技術將瀏覽器的功能添加到自己的應用程序中。從1992年開始，W3C就免費向開發者提供libwww開發庫。借助libwww，我們可以自己編寫Web瀏覽器和Web搜索工具，也可以分析、編輯或顯示HTML頁面。1999年，Microsoft在IE 5.0中引入的HTAs（HTML Applications）技術則允許我們直接將HTML頁面轉換為一個真正的應用程序。從1997年的IE 4.0開始，Microsoft為開發者提供了WebBrowser控件和其他相關的COM接口，允許程序員在自己的程序中直接嵌入瀏覽器窗口，或調用各種瀏覽器的功能，如分析或編輯HTML頁面等。Windows 98及其后的Windows操作系統甚至還利用WSH（Windows Script Host）技術將原本只在瀏覽器中運行的JavaScript、VBScript變成了可以在WIN32環境下使用的通用腳本語言，這大概也可算作我們對Web客戶端開發技術的一種巧妙利用吧。

　　服務端技術的成熟與發展

　 　與客戶端技術從靜態向動態的演進過程類似，Web服務端的開發技術也是由靜態向動態逐漸發展、完善起來的。

　 　最早的Web服務器簡單地響應瀏覽器發來的HTTP請求，并將存儲在服務器上的HTML文件返回給瀏覽器。一種名為SSI（Server Side Includes）的技術可以讓Web服務器在返回HTML文件前，更新HTML文件的某些內容，但其功能非常有限。第一種真正使服務器能根據運行時的具體情況，動態生成HTML頁面的技術是大名鼎鼎的CGI（Common Gateway Interface）技術。1993年，CGI 1.0的標準草案由NCSA（National Center for Supercomputing Applications）提出，1995年，NCSA開始制定CGI 1.1標準，1997年，CGI 1.2也被納入了議事日程。CGI技術允許服務端的應用程序根據客戶端的請求，動態生成HTML頁面，這使客戶端和服務端的動態信息交換成為了可能。隨著CGI技術的普及，聊天室、論壇、電子商務、信息查詢、全文檢索等各式各樣的Web應用蓬勃興起，人們終于可以享受到信息檢索、信息交換、信息處理等更為便捷的信息服務了。

　 　早期的CGI程序大多是編譯后的可執行程序，其編程語言可以是C、C++、Pascal等任何通用的程序設計語言。為了簡化CGI程序的修改、編譯和發布過程，人們開始探尋用腳本語言實現CGI應用的可行方式。在此方面，不能不提的是Larry Wall于1987年發明的Perl語言。Perl結合了C語言的高效以及sh、awk等腳本語言的便捷，似乎天生就適用于CGI程序的編寫。1995年，第一個用Perl寫成的CGI程序問世。很快，Perl在CGI編程領域的風頭就蓋過了它的前輩C語言。隨后，Python等著名的腳本語言也陸續加入了CGI編程語言的行列。

　 　1994年，Rasmus Lerdorf發明了專用于Web服務端編程的PHP（Personal Home Page Tools）語言。與以往的CGI程序不同，PHP語言將HTML代碼和PHP指令合成為完整的服務端動態頁面，Web應用的開發者可以用一種更加簡便、快捷的方式實現動態Web功能。1996年，Microsoft借鑒PHP的思想，在其Web服務器IIS 3.0中引入了ASP技術。ASP使用的腳本語言是我們熟悉的VBScript和JavaScript。借助Microsoft Visual Studio等開發工具在市場上的成功，ASP迅速成為了Windows系統下Web服務端的主流開發技術。當然，以Sun公司為首的Java陣營也不會示弱。1997年，Servlet技術問世，1998年，JSP技術誕生。Servlet和JSP的組合（還可以加上JavaBean技術）讓Java開發者同時擁有了類似CGI程序的集中處理功能和類似PHP的HTML嵌入功能，此外，Java的運行時編譯技術也大大提高了Servlet和JSP的執行效率--這也正是Servlet和JSP被后來的J2EE平臺吸納為核心技術的原因之一。

　　兩種重要的企業開發平臺

　 　Web服務端開發技術的完善使開發復雜的Web應用成為了可能。在此起彼伏的電子商務大潮中，為了適應企業級應用開發的各種復雜需求，為了給最終用戶提供更可靠、更完善的信息服務，兩個最重要的企業級開發平臺--J2EE和.NET在2000年前后分別誕生于Java和Windows陣營，它們隨即就在企業級Web開發領域展開了你死我活的拼爭。平臺之爭讓整個Web世界在最近的幾年里不得安寧，但從某種意義上說，也正是這種針鋒相對的競爭關系促使了Web開發技術以前所未有的速度提高和躍進。

　 　J2EE是純粹基于Java的解決方案。1998年，Sun發布了EJB 1.0標準。EJB為企業級應用中必不可少的數據封裝、事務處理、交易控制等功能提供了良好的技術基礎。至此，J2EE平臺的三大核心技術Servlet、JSP和EJB都已先后問世。1999年，Sun正式發布了J2EE的第一個版本。緊接著，遵循J2EE標準，為企業級應用提供支撐平臺的各類應用服務軟件爭先恐后地涌現了出來。IBM的WebSphere、BEA的WebLogic都是這一領域里最為成功的商業軟件平臺。隨著開源運動的興起，JBoss等開源世界里的應用服務新秀也吸引了許多用戶的注意力。到2003年時，Sun的J2EE版本已經升級到了1.4版，其中三個關鍵組件的版本也演進到了Servlet 2.4、JSP 2.0和EJB 2.1。至此，J2EE體系及相關的軟件產品已經成為了Web服務端開發的一個強有力的支撐環境。

　 　和J2EE不同的是，Microsoft的.NET平臺是一個強調多語言間交互的通用運行環境。盡管.NET的設計者試圖以.NET平臺作為絕大多數Windows應用的首選運行環境，但.NET首先吸引的卻是Web開發者的目光。2001年，ECMA通過了Microsoft提交的C#語言和CLI標準，這兩個技術標準構成了.NET平臺的基石，它們也于2003年成為了ISO的國際標準。2002年，Microsoft正式發布.NET Framework和Visual Studio .NET開發環境。早在.NET發布之前，就已經有許多Windows平臺的Web開發者迫不及待地利用Beta版本開發Web應用了。這大概是因為，.NET平臺及相關的開發環境不但為Web服務端應用提供了一個支持多種語言的、通用的運行平臺，而且還引入了ASP.NET這樣一種全新的Web開發技術。ASP.NET超越了ASP的局限，可以使用VB.NET、C#等編譯型語言，支持Web Form、.NET Server Control、ADO.NET等高級特性。客觀地講，.NET平臺，尤其是.NET平臺中的ASP.NET的確不失為Web開發技術在Windows平臺上的一個集大成者。

　　XML語言及相關技術

　 　如果說HTML語言給Web世界賦予了無限生機的話，那么，XML語言的出現大概就可以算成是Web的一次新生了。按照Tim Berners-Lee的說法，Web是一個"信息空間"。HTML語言具有較強的表現力，但也存在結構過于靈活、語法不規范的弱點。當信息都以HTML語言的面貌出現時，Web這個信息空間是雜亂無章、沒有秩序的。為了讓Web世界里的所有信息都有章可循、有法可依，我們需要一種更為規范、更能夠體現信息特點的語言。

　 　1996年，W3C在SGML語言的基礎上，提出了XML（Extensible Markup Language）語言草案。1998年，W3C正式發布了XML 1.0標準。XML語言對信息的格式和表達方法做了最大程度的規范，應用軟件可以按照統一的方式處理所有XML信息。這樣一來，信息在整個Web世界里的共享和交換就有了技術上的保障。HTML語言關心的是信息的表現形式，而XML語言關心的是信息本身的格式和數據內容。從這個意義上說，XML語言不但可以將客戶端的信息展現技術提高到一個新的層次，而且可以顯著提高服務端的信息獲取、生成、發布和共享能力。為了將XML信息轉換為HTML等不同的信息展現形式，1999年，W3C制定出了XSLT標準。同一年，IE 5.0增加了對XML和XSLT的支持。

　 　現在，網站的開發者可以直接使用XML語言發布信息了。針對不同的應用領域，人們還制定了許多專門的XML規范。例如，2001年W3C發布的SVG（Scalable Vector Graphics）1.0標準就是一種用XML語言表達的、全新的二維矢量圖形格式。開發者可以用SVG格式描述大多數已有的Flash動畫。與Flash格式相比，符合XML標準的SVG格式顯然更有利于信息交換和共享。

　 　Web本身就是一個最大的分布式應用系統。對于分布式開發而言，XML技術也大有用武之地。一個明顯的事實是，如果能讓分布式應用借助XML格式交換信息，那么，以往橫亙在分布式架構上的信息交換難題也就迎刃而解了。1999年，W3C和相關的企業開始討論設計基于XML的通信協議，2000年，W3C發布SOAP（Simple Object Access Protocol）協議的1.1版。人們把利用SOAP協議傳遞XML信息的分布式應用模型稱為Web Service。2001年，W3C發布了WSDL（Web Services Description Language）協議的1.1版。SOAP協議和WSDL協議共同構成了Web Service的基礎。隨后，J2EE和.NET這兩大企業級開發平臺先后實現了Web Service，并將其視為平臺的一項核心功能。

　 　Web Service對于Web開發者的重要意義在于，當我們需要在不同的服務端、不同的客戶端乃至不同的應用類型、不同的計算設備之間傳遞信息的時候，以往的分布式開發技術或者因為適應性不強，或者因為擴展能力不足，都難以滿足現代Web開發的需要，而Web Service正好填補了這一空白。

　　Web開發框架和應用模型

　 　2000年以后，隨著Web應用的日益復雜，人們逐漸意識到，單純依靠某種技術多半無法達到快速開發、快速驗證和快速部署的最佳境界。研究者開始嘗試著將已有的Web開發技術綜合起來，形成完整的開發框架或應用模型，并以此來滿足各種復雜的應用需求。

　 　Microsoft在客戶端的技術集成方面走在了最前面。1998年時Microsoft推出的Windows 98就可以在桌面上集成Web頁面，這實際上是將資源管理器和Web瀏覽器的功能有效地結合了起來。2000年后，Microsoft陸續推出了MSN Explorer和與之相關的MSN在線服務。這一應用模型將Web瀏覽、視頻點播、郵件處理、網上游戲、在線聊天等許多種用戶常用的Web功能集成在了一個統一的界面中。從信息利用的角度看，MSN試圖讓用戶在一個最舒適的環境中獲取足夠的信息，這種努力的確值得人們稱道。另一個與客戶端技術集成相關的例子是搜索引擎Google在2003年展示給大家的Google工具欄功能。雖然Google工具欄有炒作和廣告的嫌疑，但安裝Google工具欄之后的IE瀏覽器將信息瀏覽和信息檢索有機地結合了起來，這種小小的功能改進確實是對用戶的體貼和幫助。

　 　在Web服務端，2000年以后出現了幾種主要的技術融合方式。首先，越來越多的Web開發環境開始支持MVC（Model-View-Contorller）的設計模型，為開發者提供了全套的開發框架。實際上，J2EE和.NET平臺本身就是這種開發框架的典型代表。其次，門戶服務（Portal Server）和Web內容管理（Web Content Management）在最近幾年里成為了應用集成的重點模型。這兩種應用模型可以直接為開發者或最終用戶提供構建Web應用的高級平臺，可以讓Web開發和信息發布工作大為簡化。在商業軟件領域，這一類應用的例子包括Microsoft的SharePoint、IBM的WebSphere Portal、FileNet的Web Content Manager等等。開源項目在Web開發框架和應用模型方面表現得非常積極，Struts、Jetspeed、jPortlet、Cocoon、Lenya、XOOPS等都是開源世界里與MVC開發框架、門戶服務和Web內容管理相關的優秀解決方案。

　 　當然，技術集成絕不等于技術堆砌。一些Web站點和Web應用的開發者把XML語言、MVC框架等時髦技術拼湊起來，卻不管它們是否能適應具體的應用環境，結果，他們的系統要么運行效率低下，要么功能殘缺不全。反之，一個值得注意的事實是，像新浪、搜狐或網易這樣的門戶網站，在他們的信息發布頁面（如新聞頁面）里，盡管信息內容時刻都在刷新，但Web服務器上存放的始終都是靜態的HTML頁面。這種"落后技術"的優點是，在大量并發訪問的情況下，門戶網站的響應速度仍然很快。深入到技術層面，我們通常會驚訝地發現，這些網站使用的大多是自行研發的Web內容管理系統。當網站的內容編輯提交新的信息時，系統會自動將信息轉換為HTML格式，發布到Web服務器集群的每一個結點上。在新浪網的一個角落里，我們可以找到"新浪網站發布系統"的研發歷程：

　　V 1.0（1997）：基于文件的版本，實現新聞首頁、正文和專題的發布。
　　V 1.1（1998/12）：采用數據庫后臺、實現跨服務器發布，自動化程度高。
　　V 2.0（1999/3）：創立模版和域的全新概念，奠定了該系列的基本設計思路。
　　V 2.1（1999/9）：增加周邊模塊，如搜索、自動采集。
　　V 3.0（2000/1）：優化傳輸方式，增加相關新聞和評論。
　　V 3C（2000/6）：V3.0的編譯版，也是商業版的原型。
　　V 3.1（2000/7）：優化數據庫結構，采用內存CACHE大幅提速，增加了集中監控功能。
　　V 3.1C（2000/8）：商業用測試版本。
　　V 3.2（正在制作中）：重點解決備份系統的自動化切換，在機制上實現永不宕機。

　　這一份有趣的歷史記錄再一次印證了我關于Web開發技術的基本觀點：一種技術只要能為用戶提供高水平的信息服務，它就是最好、最先進的技術。

　　 Web開發技術的未來

　　所有人都在關心Web的發展前景，所有人都想知道十年以后的Web會長成什么樣子。要回答這些問題，沒有誰比W3C更有權威了。W3C明確地告訴我們，Web的未來是語義化的Web（Semantic Web）。今天的Web可以自如地生成、傳遞和展現各式各樣的信息，但它還只是一個信息的"容器"，很難揭示出信息本身的內容和特性。與此相對的是，未來的語義化Web是一種懂得信息內容的Web，是真正的"信息管理員"。

　　從技術角度看，XML語言統一了信息的表達方式，但這離揭示信息內容的目標還相距甚遠。1998年，W3C和一些研究機構開始對元數據（Metadata）進行研究。元數據是描述數據的數據，可以揭示信息的內容特性。1999年，NetScape提出的RSS（Rich Site Summary）建議標準是用元數據技術描述新聞等信息內容的第一次嘗試。1999年，W3C的研究小組提出了RDF（Resource Description Framework）標準草案。RDF在XML語法的基礎上，規定了元數據的存儲結構和相關的技術標準。使用RDF語言，我們可以用統一的、可交換的格式揭示出信息本身的各種特性。2001年，W3C又開始著手制定OWL（OWL Web Ontology Language）標準。OWL語言也是一種符合XML標準的語言，它比RDF又前進了一步，可以更加深入、細致地描述信息內容。在RDF和OWL語言的幫助下，我們能讓Web上的信息內容變得更容易理解、更便于交換和共享。2003年，W3C成立了語義化Web Service研究小組（Semantic Web Services Interest Group），研究在Web Service中加入語義技術的相關問題。2004年2月，W3C宣布RDF和OWL標準正式成為W3C的建議方案，這標志著語義化Web的大廈已經破土動工。

　　隨著語義化Web的誕生和發展，Web開發技術也必將經歷更為重大的變革。可以預見的是，在未來的幾年里，還會有許多新的開發技術或開發平臺出現。從靜態技術到動態技術，從開發平臺到應用模型，從傳統Web到語義化Web……為了讓更多的人獲得更有價值的信息服務，Web開發者們也許還會經歷一次又一次的技術浪潮，還會面臨更為嚴峻的技術挑戰，但這和信息共享的最高目標相比，又算得了什么呢？

所謂的流星閃過，留下一堆影子，其實就是一系列同樣的星星次第爆發而已。

筆記本裝的系統是Win 7，很煩人。
一段時間沒用筆記本上面的Flash CS4和Flash Builder 4，今天上的時候發現提示說Licensing for this product has expired，然后兩個都要求輸入序列號了，而且FB4輸入啥序列號都不行，懷疑是我的版本Out了一時沒找到序列號，要么就下載個最新的，要么就下載回FB3，于是重新下載FB3，但是要等很久，于是趁此機會重新找找看能否找到FB4的序列號解決這個問題。

回顧之前解決CS4這個問題的方法是：

要先往 C:\WINDOWS\system32\drivers\etc\Hosts 中最后面添加
127.0.0.1 localhost
127.0.0.1 activate.adobe.com
127.0.0.1 practivate.adobe.com
127.0.0.1 ereg.adobe.com
127.0.0.1 activate.wip3.adobe.com
127.0.0.1 wip3.adobe.com
127.0.0.1 3dns-3.adobe.com
127.0.0.1 3dns-2.adobe.com
127.0.0.1 adobe-dns.adobe.com
127.0.0.1 adobe-dns-2.adobe.com
127.0.0.1 adobe-dns-3.adobe.com
127.0.0.1 ereg.wip3.adobe.com
127.0.0.1 activate-sea.adobe.com
127.0.0.1 wwis-dubc1-vip60.adobe.com
127.0.0.1 activate-sjc0.adobe.com
::1 localhost

然后運行軟件，會提示輸入序列號，這時就輸入這些：
1325-1110-3786-4687-3270-8979

問題又來了，我用的是自己的賬戶登錄，沒有管理員權限，Win7死活不給我修改系統文件，于是只得繼續百度：
http://www.ylmf.net/read.php?tid=1374858&page=e
好長，長到我都快沒耐心了~~最后總算堅持搞定了，于是可以改hosts，其實我改它不止是因為現在要用，估計以后會經常要改，它是用來設置主機域名映射的。

然后CS4沒問題了，剛好FB3下載好了，就安裝，總算搞定~

《Flex 3 權威指南》這本書確實不錯，我要利用晚上下班的時間搞定它。

（不定期更新）
1.負責Web網游客戶端開發
2.針對開發功能進行分析、設計和實現
3.針對公司的需求，制作Flash AS3演示
1.使用Action script兩年以上 ，精通AS3編程及Flex ，熟悉OOP
2.一年以上團隊管理經驗，有主持大型Flash項目和多人合作項目開發經驗 。
3.精通Action script與Java 后臺做Socket網絡通訊編程、熟悉XML、Ajax、JavaScript及數據庫等技術
4.熟知游戲或軟件開發流程，熟知游戲常規算法。
5.掌握多種開源框架，善于使用設計模式開發，掌握FLEX/FLASH代碼和素材安全機制以及性能優化技術。
6.程序編碼規范，文檔編寫能力良好。
7.具備一定項目管理知識，能合理分配任務，能協調并指導其他團隊成員完成項目開發。
8.熱愛游戲行業，善于溝通和鉆研技術，工作認真、負責、有激情、能承擔較大工作壓力
良好的數學、物理、計算機及操作系統知識，熟悉各種運算法則和公式；
 有跨平臺的良好開發能力，Java（J2ME/J2SE）

具體Flash技術：
事件機制：對AS3的時間冒泡機制了如指掌并會依照實際情況進行優化
安全機制：有能避免安全砂箱出錯的處理辦法
Preloader機制：深入了解Proloader機制，并且優化過Proloader的加載順序
模塊化編譯機制：知道原理并進行過優化
Flex的Profile使用：嘗試使用他來優化我的程序
垃圾回收：清楚理解垃圾回收以及內存泄露的關系，有針對性地進行優化
采用Flash Builder, Flex Builder, FDT, Flash Develop開發
IDE技巧：編寫過jsfl腳本完成重復的工作
外部資源(MovieClip, Image, Font)使用：針對外部資源進行過優化
嵌入字體：用IDE或者代碼方式嵌入字體，并解決過相應BUG
有自己的開發類庫
用AIR開發過項目
能通過UML圖表達自己的思想以及程序邏輯
知道MVC的優劣和適用范圍
使用過UI框架（ASwing，Flex）、輔助類庫（As3Corelib,Swfaddress,Tweenlite)、常見MVC框架(PureMVC,Cairngorm,RobotsLegs)、3D類庫(Pv3d,Away3d)
用過幾種IOC開源框架

Flash動畫設計與開發：
崗位職責： 
1.能夠獨立構建全Flash框架下的交互站點 ; 
2.為站點創作合適而充滿樂趣的動效表現 ; 
3.項目前期/需要對框架的合理性提出明確想法和可行性計劃 ; 
4.項目中期/需要從動效及AS部分對交互體驗進行實施和效果負責 ; 
5.項目后期/需要了解及測試體驗成果并將成果進行知識轉化 ; 
6.我們需要你積極的與互動研究小組的其它動效或AS專家、設計師以及后臺功能程序師進行多方面溝通 ; 
7.對思路與想法通過故事腳本或流程圖的方式表達你的意圖 ; 
8.知識分享與繼承，包括了培訓和常用模塊建設. 
任職要求：
1.2年以上Flash應用經驗 ; 
2.動畫特效經驗豐富,具備音樂編輯能力 ; 
3.熟悉Action Script,了解面向對象編程，精通FLASH軟件，熟悉網站技術 ; 
4.愿意深入了解用戶可用性，對交互設計有一定研究 ; 
5.有獨特的視角,富有創意表現欲; 
6.良好的團隊溝通和協作能力 ; 
7.具備嚴謹的開發規范和書面文檔能力; 
8.具備職業道德和職業恒心者優先

一個Flash項目團隊需要的人員：
工作職責：承接并如期交付我司交予的項目，保證項目質量。
要求：
1、有較成熟的flash動畫項目開發隊伍（4人以上），
2、熟悉Adobe Flash 各版本的操作；團隊中至少兩人精通Action Script，能制作flash游戲及互動動畫。
3、團隊中至少一人有美術功底，有較強的手繪能力，能設計卡通人物造型，繪制卡通場景；
4、團隊中至少一人熟練應用photoshop, AI等圖像處理軟件；
5、工作認真負責，有時間觀念及團隊精神。 
1、應征團隊請列明主要項目經驗及提交3個以上項目成品（2個互動游戲）
2、請列明隊伍人數及分工情況。 .


AS3.0中的異步異常處理捕捉 http://www.caoyusky.com/blog/as3-try-catch/
AS3 中URLLoader和Loader的區別 http://www.jb51.net/flash/actionscript/18319.html
玩轉Flash AS 3D  http://space.flash8.net/bbs/viewthread.php?tid=323970&highlight
asp.net上傳文件權限問題 http://www.iecn.net/read-html-tid-29087.html
TMD,加班中，下被子絕對不當程序員，文件上傳權限問題 http://study.qqcf.com/web/720/261271.htm
一個在服務器上模擬客戶端上傳文件的問題 http://topic.csdn.net/t/20060506/03/4732107.html
FLASH AS3 urlloader調用ASP.NET,2032流錯誤 http://zhidao.baidu.com/question/70037072.html
FLASH asp.net后臺通訊 IOERROR2032的問題,完美解決!http://hi.baidu.com/kidcdf/blog/item/623114d15a0132d5562c84c0.html 
夢境家園flash 3D虛擬社區游戲 http://tieba.baidu.com/f?kz=614183511
Flash AS 3D貼圖教程[1]  http://hgfghw1.javaeye.com/blog/633027
as3和后臺數據交互(轉) http://cid-d37fb67ef2993635.spaces.live.com/blog/cns!D37FB67EF2993635!157.entry
asp.net上傳文件 http://luckyjaky.javaeye.com/blog/350697

哼哼哈嘿。
有些歌能夠讓人很是亢奮，提起精神工作。

出埃及進行曲
蝶舞天涯
男兒當自強

誰是大英雄

再推薦一些好聽的歌：
偏愛
擦肩而過——李圣杰
花樣年華
南山憶
廬州月
平凡的浪漫

一、 分享第一條經驗：“學歷代表過去、能力代表現在、學習力代表未來。”
      其實這是一個來自國外教育領域的一個研究結果。相信工作過幾年、十幾年的朋友對這個道理有些體會吧。
    但我相信這一點也很重要：“重要的道理明白太晚將抱憾終生！”所以放在每一條，讓剛剛畢業的朋友們早點看到哈！
二、   一定要確定自己的發展方向，并為此目的制定可行的計劃。
    不要說什么，“我剛畢業，還不知道將來可能做什么？”，“跟著感覺走，先做做看”。因為，這樣的觀點會通過你的潛意識去暗示你的行為無所事事、碌碌無為。
    一直做技術，將來成為專家級人物？向管理方向走，成為職業經理人？先熟悉行業和領域，將來自立門戶？還是先在行業里面混混，過幾年轉行做點別的？這很重要，它將決定你近幾年、十年內“做什么事情才是在做正確的事情！”。
三、
     軟件開發團隊中，技術不是萬能的，但沒有技術是萬萬不能的！
    在技術型團隊中，技術與人品同等重要，當然長相也比較重要哈，尤其在MM比較多的團隊中。在軟件項目團隊中，技術水平是受人重視和尊重的重要砝碼。無論你是做管理、系統分析、設計、編碼，還是產品管理、測試、文檔、實施、維護，多少你都要有技術基礎。
    算我孤陋寡聞，我還真沒有親眼看到過一個外行帶領一個軟件開發團隊成功地完成過軟件開發項目，哪怕就一個，也沒有看到。倒是曾經看到過一個“高學歷的牛人”(非技術型)帶一堆人做完過一個項目，項目交付的第二天，項目組成員扔下一句“再也受不了啦！”四分五裂、各奔東西。那個項目的“成功度”大家可想而知了。四、   
詳細制定自己軟件開發專業知識學習計劃，并注意及時修正和調整(軟件開發技術變化實在太快)。
    請牢記：“如果一個軟件開發人員在1、2年內都沒有更新過自己的知識，那么，其實他已經不再屬于這個行業了。”
     不要告訴自己沒有時間。來自時間管理領域的著名的“三八原則”告誡我們：另外的那8小時如何使用將決定你的人生成敗！本人自畢業以來，平均每天實際學習時間超過2小時。
五、
    書籍是人類進步的階梯，對軟件開發人員尤其如此。
   書籍是學習知識的最有效途徑，不要過多地指望在工作中能遇到“世外高人”，并不厭其煩地教你。
    對于花錢買書，我個人經驗是：千萬別買國內那幫人出的書！我買的那些家伙出的書，100%全部后悔了，無一本例外。更氣憤的是，這些書在二手市場的地攤上都很難賣掉。“擁有書籍并不表示擁有知識；擁有知識并不表示擁有技能；擁有技能并不表示擁有文化；擁有文化并不表示擁有智慧。”只有將書本變成的自己智慧，才算是真正擁有了它。
六
      不要僅局限于對某項技術的表面使用上，哪怕你只是偶爾用一、二次。“對任何事物不究就里”是任何行業的工程師所不應該具備的素質。
    開發Windows應用程序，看看Windows程序的設計、加載、執行原理，分析一下PE文件格式，試試用SDK開發從頭開發一個Windows應用程序；用VC＋＋、 Delphi、Java、.Net開發應用程序，花時間去研究一下MFC、VCL、J2EE、.Net它們框架設計或者源碼；除了會用J2EE、 JBoss、Spring、Hibernate等等優秀的開源產品或者框架，抽空看看大師們是如何抽象、分析、設計和實現那些類似問題的通用解決方案的。
    試著這樣做做，你以后的工作將會少遇到一些讓你不明就里、一頭霧水的問題，因為，很多東西你“知其然且知其所以然”！
七
      在一種語言上編程，但別為其束縛了思想。
    “代碼大全”中說：“深入一門語言編程，不要浮于表面”。深入一門語言開發還遠遠不足，任何編程語言的存在都有其自身的理由，所以也沒有哪門語言是“包治百病”的“靈丹妙藥”。編程語言對開發人員解決具體問題的思路和方式的影響與束縛的例子俯拾皆是。
    我的經驗是：用面對對象工具開發某些關鍵模塊時，為什么不可以借鑒C、C51、匯編的模塊化封裝方式？用傳統的桌面開發工具(目前主要有VC++、Delphi)進行系統體統結構設計時，為什么不可以參考來自Java社區的IoC、AOP設計思想，甚至借鑒像Spring、Hibernate、JBoss等等優秀的開源框架？在進行類似于實時通信、數據采集等功能的設計、實現時，為什么不可以引用來自實時系統、嵌入式系統的優秀的體系框架與模式？為什么一切都必須以個人、團隊在當然開發語言上的傳統或者經驗來解決問題？？？“他山之石、可以攻玉”。
    八
    眾所周知，對軟件開發人員而言，有、無經驗的一個顯著區別是：無經驗者完成任何任務時都從頭開始，而有經驗者往往通過重組自己的可復用模塊、類庫來解決問題（其實這個結論不應該被局限在軟件開發領域、可以延伸到很多方面）。這并不是說，所有可復用的東西都必須自己實現，別人成熟的通過測試的成果也可以收集、整理、集成到自己的知識庫中。但是，最好還是自己實現，這樣沒有知識產權、版權等問題，關鍵是自己實現后能真正掌握這個知識點，擁有這個技能。
    養成總結與反思的習慣，并有意識地提煉日常工作成果，形成自己的個人源碼庫、解決某類問題的通用系統體系結構、甚至進化為框架。  
九
    工程師的內涵是：以工程師的眼光觀察、分析事物和世界。
    一個合格的軟件工程師，是真正理解了軟件產品的本質及軟件產品研發的思想精髓的人（個人觀點、歡迎探討）。
掌握軟件開發語言、應用語言工具解決工作中的具體問題、完成目標任務是軟件工程師的主要工作，但從軟件工程師這個角度來看，這只是外在的東西，并非重要的、本質的工作。學習、掌握軟件產品開發理論知識、軟件開發方法論，并在實踐中理解、應用軟件產品的分析、設計、實現思想來解決具體的軟件產品研發問題，才是真正的軟件工程師的工作。站在成熟理論與可靠方法論的高度思考、分析、解決問題，并在具體實踐中驗證和修正這些思想與方式，最終形成自己的理論體系和實用方法論。
十、
    書到用時方恨少，不要將自己的知識面僅僅局限于技術方面。
    盡量參加開源項目的開發、或者與朋友共同研制一些自己的產品，千萬不要因為沒有錢賺而不做。網絡早已不再只是“虛擬世界”，網上有很多的開源項目、合作開發項目、外包項目，這都是涉獵工作以外的知識的絕好機會，并且能夠結識更廣的人緣。不要因為工作是做ERP，就不去學習和了解嵌入式、實時、通信、網絡等方面的技術，反過來也是一樣。如果當別人拿著合同找你合作，你卻這也不會，那也不熟時，你將后悔莫及。