http://blog.csdn.net/fuchunyi/archive/2006/10/22/1345708.aspx
這周去拜訪一個客戶，他們正在實施RUP，問及效果如何，聽到了一些關于迭代化開發的新問題。
這位客戶是一家集成商，主要為甲方開發應用軟件系統。實施迭代化開發的主要目的是控制項目風險，應用項目的最大風險一般都在于需求，采用迭代化可以通過迭代產生的原型系統來收集甲方客戶的反饋，從而及早修正對于客戶需求的誤解。但是開發團隊并沒有象預想中那樣收集到甲方的反饋，甲方還是習慣于用傳統的瀑布模型來評價、驗收系統，他們并沒有對項目過程中交付的原型系統進行認真的確認，所以也沒有太多的意見反饋給開發團隊，很多需求的變更還是要到系統正式驗收時才被提出來。因為在甲方的觀念中，他們還不太認可項目結束之前所提交的中間結果。
另外，項目的合同是按照瀑布模型的階段來簽的，需求分析、概要設計、詳細設計、編碼完成、驗收測試是項目回款的里程碑。采用迭代化開發之后，在原定的概要設計交付時間點上，可能需求分析和概要設計都只完成了部分的工作，比原定計劃要晚一些；而詳細設計和編碼工作都已經開始了一部分，比原定計劃要提前一些。這樣就不能按照原定時間點來要求甲方就需求分析和概要設計那部分工作量付款，對于中國的集成商而言，項目回款是比合同簽定都要重要的工作。
這些問題給我們的經驗教訓是應用項目開發采用迭代化開發流程，也需要讓客戶理解這一點，項目工作說明書中的工作單元內容也需要跟迭代化開發流程來符合。軟件開發流程關系到所有的涉眾(Stakeholder)，僅僅是開發團隊理解并實施這一流程是不夠的。
還有一個反饋來自于很多項目團隊，認為迭代化開發概念上聽起來很有道理，但在項目中實施后往往感覺不到采用這處方法后對項目有什么太大的幫助。迭代化開發的主要目的在于控制項目風險，常見的項目風險如技術架構、客戶需求等等。但是日常工作中的項目往往沒有太多的風險，我們開發的往往是重復性的項目，電信事業部做的就是不同運營商的BOSS項目，社保事業部就是為不同省份開發社保系統，雖然有特殊需求，但系統架構和基本需求完全一樣；更多的項目是對現有系統的維護性開發，實現客戶提出的變更請求和改正軟件缺陷，一般不會涉及到系統架構的改動。在這種類型的項目中，迭代化開發體現的不是對風險的控制，而是系統增量式開發而不斷給涉眾所帶來的信心和鼓舞，開發人員可以在較斷的時間周期內看到自己所開發的系統可以“跑”起來了，客戶則可以看到整個項目在不斷地往前推進。
媽的, 想起來就有氣, 現在的公務員一個比一個牛, 本來應該為人民服務, 態度卻一個比一個差....
最近想辦居住證續辦, 想打個電話咨詢一下, 試了N多個, 有的 還好借了告訴你個號碼, 讓你去打, 但一直戰線, 更有的那起來就掛掉, 拿起來就掛,,,,,,
TNND!!!!
http://www.bcb-tools.com/AuthorNotes.htm
http://dotnet.csdn.net/n/20061011/95958.html
微軟首席執行官鮑爾默表示，提前部署（on-premise）軟件與通過互聯網發布的服務之間的界線在日益模糊，微軟正在順應這一業界趨勢。
鮑爾默在Gartner 的Symposium/ITxpo 會議上接受了Gartner分析師史密斯和伊馮的采訪。鮑爾默在采訪中說，許多網站可以被稱作“點擊運行”，服務通過網站發布，但在PC上運行。
他表示，我認為我們正處于一種轉型中，軟件正在由前互聯網時代發展到我們所謂的“Live時代”，網站提供了“點擊運行”能力，但軟件仍然需要在PC上運行。
由于有大量的臺式機和服務器軟件產品，與Salesforce.com或Google相比，微軟對托管服務的態度還不夠積極。
據鮑爾默稱，微軟計劃推出面向消費者和企業客戶的服務化軟件，提供通過互聯網的服務和企業防火墻后面的服務器。
去年，微軟將Windows 和開發者工具部門與負責MSN Web 服務的部門進行了整合，它目前正在開發一系列名為Live的托管服務，其中一些服務旨在補充現有的“提前安裝”軟件。
鮑爾默表示，軟件+ 服務與服務化軟件之間的差別在于人們是否想利用手機、PC的處理能力。甚至考查一下目前的互聯網服務，它們也都使用了客戶端的處理能力，例如AJAX、即時通訊服務。
鮑爾默表示，在這一服務化大潮中，盡管不能永遠保持第一，但微軟不會放棄。他說，我們或許不是第一，但我們在不斷努力。在搜索方面也是一樣，我們不會輕言放棄。
親愛的技術支持： 我急需您的幫助。我最近將"女朋友7.0"升級到"妻子1.0"，發現這個新程序意外地啟動了孩子生產程序，而且占用了大量的空間和珍貴的資源。這在產品的使用手冊中沒有提到。 此外"妻子1.0"自動將自己安裝到其他的所有的程序中，它隨系統同時啟動，監控整個系統的狀態。 "男人夜出2.5"和"高爾夫5.3"無法再運行，一旦運行該程序系統即行崩潰。試圖運行 "周日足球6.3"經常失敗，而"周六購物7.1"卻代之運行?？磥砦覠o法保留"妻子1.0"，因為它和我喜歡運行的任何程序都不相容。我打算回到"女朋友7.0"，可是這個程序又無法卸載。 請您幫幫我吧！ 喬 給喬的回信: 親愛的喬：這是個很普通的問題，產生于你對基本原理的不了解。很多的男人健"女朋友7.0"升級到"妻子1.0"，以為"妻子1.0"是一個"實用與娛樂程序"。然而"妻子1.0"卻是個操作系統，是被設計用來運行所有程序的。你不可能清除"妻子1.0"，也不可能回到"女朋友7.0"，因為"妻子1.0"的設計中不具有這個功能，無論是卸載、刪除或是清除已經安裝在系統中的這些程序文件，都是不可能的。 有些人曾試圖安裝"女朋友8.0"或者"妻子2.0"，結果是產生了更多的問題(參見手冊中的贍養費/孩子的養育/律師費用)。我安裝過"妻子1.0"，我建議你保持現在的安裝狀態，妥善解決遇到的困難。 當任何錯誤或問題出現的時候，不論你認為是什么原因引起的，你必須運行"C:＼我道歉"程序，并且避免使用"退出鍵"。必要時可能需要運行"C：＼我道歉"多次，希望最終能使操作系統恢復到初始狀獺。 "妻子1.0"雖然是一個需要高保養的程序，但同時對人可能是非常有益的。要想充分地利用它，需要買些額外的軟件比如"鮮花2.0"和"巧克力5.0"。不要在任何情況下安裝"秘書(短裙版)"，因為"妻子1.0"不支持這種程序，而且系統多數時候肯定會崩潰。 祝你好運！
Life like a long run contest
e.g 3000 meters.
sb abort it at 1000 meters.
sb abort at 2000
but only ones who finished running are sucessfully.
But who will became these ones???
http://www.javaresearch.org/article/showarticle.jsp?column=2&thread=32387
摘要
我們常常在Web應用中需要啟動一個自己寫的服務，本文的目的是給你提供一個解決方案。
原理
本方案的原理是寫一個實現了ServletContextListener接口的類，該類中有兩個方法： public void contextInitialized(ServletContextEvent sce)，它是在應用啟動時調用；另一個方法是：public void contextDestroyed(ServletContextEvent sce)，該方法是在應用結束時調用。把我們要啟動的后臺應用邏輯放在contextInitialized方法中實現；把釋放后臺應用占用資源的工作放在contextDestroyed來處理。但我們啟動的后臺任務常常是有要求的，比如時間，頻率等，我在這里使用了一個開源組件：quartz。
步驟
1.寫業務調用類：
// DumbJob.java
import org.quartz.*;
import java.util.*;
public class DumbJob implements Job {
public DumbJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException
{
//在這里寫業務處理代碼。什么，你不知道？那你別問我！！:-<
}
}
本類的主要功能是由quartz中調度類按照指定的規則進行調用執行必要的業務邏輯。
2.寫調度類
// TestShedule.java
import org.quartz.*;
import java.util.*;
public class TestShedule{
static SchedulerFactory schedFact = new org.quartz.impl.StdSchedulerFactory();
static Scheduler sched;
public static void run()throws Exception{
sched = schedFact.getScheduler(); //獲取調度管理器
JobDetail jobDetail = new JobDetail("myJob",
sched.DEFAULT_GROUP,
DumbJob.class);//創建工作
CronTrigger trigger = new CronTrigger("myTrigger","test","0/10 * * * * ?");//創建觸發器
sched.scheduleJob(jobDetail, trigger); //添加到調度管理器中
sched.start();//啟動調度管理器
}
public static void stop()throws Exception{
sched.shutdown();
}
}
本類的目的是設置調用規則，在這里我用了“0/10 * * * * ?”表示每10秒鐘就執行一次，有關表達式的說明請參閱quartz的api文檔。
3.編寫服務啟動類：
//ServiceLoader.java
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
public class ServiceLoader implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
try{
TestShedule.run();
}catch(Exception ex){
System.out.println(ex.getMessage());
}
}
public void contextDestroyed(ServletContextEvent sce) {
try{
TestShedule.stop();
}catch(Exception ex){
System.out.println(ex.getMessage());
}
}
}
在contextInitialized中調用TestShedule.run()啟動后臺任務；在contextDestroyed中調用TestShedule.stop()停止后臺任務。
4.部署服務啟動類
在web.xml文件中增加如下一行配置：
rootServiceLoader index.html
5.啟動web服務即可。
總結
其實實現這個功能的方法很多，我在這里是應用了ServletContextListener接口和開源api quartz，希望能對你的開發有所幫助。
資源
quartz: http://www.opensymphony.com/quartz
ServletContextListener在javax.servlet包中
http://blog.csdn.net/myan/archive/2006/09/25/1281151.aspx
相信很多人都聽過一個禪宗故事，說是兩個僧人趕路，趟過一條小河的時候，看到一個漂亮的少婦困于其中，向他們呼救。其中一個有心施以援手，但想到佛家的色戒，便猶豫起來，不知如何是好?？闪硪粋€和尚卻大大咧咧地沖過去，抱起少婦，趟過小河。于是前者的心里就很不舒服，一路上悶悶不語，后來實在忍不住，就問自己的同伴，既然身為佛門中人，怎能不顧清規戒律，如此輕薄。然而那位和尚卻回過頭來，淡淡地說：“我已經把她放下了，你還抱著呢？”
也許不太貼切，但是這幾天中外豪杰們圍繞Ruby和Rail爆發的口水戰，讓我不由得想起這個小故事。
前幾天著名大嘴Joel Spolsky在自己的一畝三分地里對Ruby進行了FUD性的攻擊，引發互聯網上一片口水戰，Ruby之父matz和Rails之父DHH都卷入其中。似乎是要與此相呼應，在國內技術論壇上，這幾天圍繞Ruby的爭論也突然攀登新高峰了。國外的大氣候和國內的小氣候都有共同特點，就是站在傳統技術立場上的人對于RoR的火爆看不下去了，首先站出來發難，從而引發Ruby支持者們的回擊，然后雙方廝殺在一起，連帶旁邊相干不相干的看熱鬧的、拉架的、含沙射影的、慷慨激昂的，瞬間就浩浩蕩蕩，橫無際涯了。而爭論來爭論去，無非還是Ruby的性能問題、可用性問題、前景問題，等等等等。
可能是老生常談了，但倒R派的觀點讓我想起多年前我們這些C++ fans對Java的鄙視言論。那個時候C++程序員們說，Java只能用來在頁面上用applet作一些可笑的小動畫，Java只能對對火柴棍排序，Java慢得像牛車，Java有內存泄露，Java狂耗內存，Java愚蠢的弱類型容器可以把鯨魚裝進一個筆筒，Java居然沒有指針，Java做不了系統程序設計，Java寫不了操作系統，Java解決不了我手頭的超超級復雜的巨牛無比的難題，諸如此類，不一而足。冠冕堂皇的理由可以找出一大籮筐，但大皮襖下面無非就是一個“私”字而已。骨子里的想法是，我費了好大的牛勁才混了個C++三品頂戴，你Java一鬧騰，就把我的似錦前程給攪黃了，怎能不妒火中燒，羞憤交加？
可是這些年過去了，當時我們吐那點酸水起了什么作用了嗎？Java統治了企業計算，統治了手機應用開發，統治了大學教育。不但如此，Java在開源領域里也如日中天，接Eclipse之威在桌面應用中也占了一座大山頭。一些傳統上屬于系統程序的項目，比如編譯器、語法分析器、高性能的服務器軟件等等，也大量轉用Java開發。不錯，Java還是不能用來寫F-22戰斗機的火控系統，但是這跟我們這些坐在cubic里寫民用軟件的家伙有個鬼的關系！人們對于簡單、標準化和生產率的要求不可阻遏地突破了早期對Java筑起的FUD防線。面對Java的空前絕后的成功，我們這些當年曾經對革命力量翻白眼吐舌頭的家伙，在沉默的面對現實之后，已經完成了一次觀念上的滌蕩。我們已經認識到，技術的發展趨勢是不以個人利益為轉移的，干這行就要有順應技術大潮的勇氣，要有不斷破舊立新的魄力。我覺得我已經放下了曾經有的那種盲目的固執和一廂情愿。
然而時間沒過多久，隨著Java成長和騰達起來的一代人（其實不少也就是我的同齡人），又開始重蹈覆轍。面對以Ruby為代表的新興動態語言的蓬勃發展，他們也有點坐不住了?？扛锩鸺业娜俗钆赂锩?，當年的下里巴人翻身做主了，搖身一變成闊佬了，就開始對新的革命力量擺譜使臉色，甚至以FUD戰術加以彈壓了。與當年如出一轍，手段還是以攻為守，情緒還是慷慨激昂，筆法還是義正言辭，什么Ruby未經驗證啦，什么Ruby性能低劣啦，什么Rails可擴展性不佳啦，什么Ruby不能解決“大型的”、“復雜的”、“企業級的”、“高性能的”問題啦。最要命的是，哪怕自己90%的時間不過是在字符串處理，這些闊佬們也還是一致宣稱自己做著世界一流的、大型的、復雜的、企業級的、非Java不可、沒Java不行、沒Java就要上吊抹脖子跳樓挖坑的巨牛無比的大項目，聽著讓人心驚肉跳兼之無比崇敬。你說Java還能火幾年？我說怎么也得5年！5年？那是上升期！少說十年，后面還有平臺期。你還別不服，反正我退休之前Java說什么也別想涼下來，誰也別想威脅我的頂戴花翎。企業級啊，架構師啊，經驗啊，高手啊，我混成這樣我容易嗎我？誰冒出來我就跟誰急，我就用口水淹死他！
可惜，這些大話對于我這種記性不幸沒那么差勁的人來說，太似曾相識了，讓我一眼就看出這言論背后的“私”字來。想來也真是輪回，當年我們C++這一批人放下的東西，原來你們Java這一批人還抱著呢。不過，技術的大潮真的是后浪推前浪，往后看吧，我相信，當年C++擋不住的東西，今天Java也擋不住。大趨勢已經擺在這了，接不接受、什么時候接受，那是個人的問題，但是總體的發展是無可逆轉的。
Ruby的興起，其實只不過是一個積累了幾十年的技術趨勢的能量釋放。世界上第二個程序設計語言Lisp及其后續家族成員都是最最動態的語言。早在七十年代，伴隨著圖形界面的出現，Smalltalk就以其純粹的面向對象和純粹的動態性獲得有識之士的認可。自1986年代Perl出現以來，大量開發者就認識到，動態語言開發效率高，限制少，能夠自由的表達思想，輕松完成在傳統語言中非常困難的工作。很多人都預言動態語言遲早會成為主流。然而在整個1990年代，無論是計算機硬件條件還是軟件工程的水平，都還不夠成熟，再加上Perl自身存在一些問題，動態語言始終只是作為主流語言的一種有力的補充而存在。2000年之后，PHP大流行，在Web開發領域三分天下有其一。但是PHP本身完全是為Web而做，當擴展到其他領域時，就凸顯出先天不足的劣勢，因此地主穩坐，霸業難成。直到現在，無論是硬件條件、軟件開發的方法，還是客觀應用環境都逐漸成熟，在這個時候，Ruby借Rails框架贏得廣泛關注，當然不是偶然的現象。在TIOBE全球程序設計語言排名表中，Ruby排名一年間跳升15位，而根據O’Reilly公司對于圖書市場的統計，Ruby相關書籍的銷量在2005年增長15倍的基礎之上，今年又增長了7倍，已經超過Python和Perl。再看看是誰在關注Ruby，拋開一手把Ruby炒熱的“Pragmatic Programmer二人組”Dave Thomas和Andy Hunt不說，一大批編程老槍都在嘗試或者已經轉向Ruby，這其中的著名人物包括Robert C. Martin、Martin Fowler、Bruce Tate等。如果這些還不夠令人印象深刻的話，我們應該注意一下近期有關Ruby的一些事件。最近Sun雇用了開源項目JRuby的兩名主要開發者，讓他們可以全職開發JRuby，從而正式將Ruby語言搬上JVM。同時，微軟也在上個月的一次有關.NET語言的技術會議上邀請RubyCLR的主要開發者John Lam發表演講，外界傳言他將加入IronPython開發者Jim Hugunin所在的團隊，從而加速Ruby for .NET的開發進程。另一個致力于Rich Internet Application的軟件巨頭Adobe于幾天前剛剛發布了用以將Flex 2.0整合到Ruby on Rails中的SDK。對于那些整天盯著巨頭們臉色行事的人來說，這些消息就算不是金口玉言，至少也是明確的跡象了吧。
然而，比上面一切都更為重要的是，今天的世界已經變了，已經不是15年前C++統治一切的那個世界，也不是10年前Java中彩票的那個世界，甚至也不是5年前Visual Basic狂練葵花寶典的那個年代?；ヂ摼W改變了太多的東西，經濟形態和公司業務的形式和途徑都已經并且仍在發生迅速的、根本性的變化。開放、互聯、敏捷、整合、平等、自由、高速、專業，所有這些給我們帶來了新的經濟運行模式，也對軟件的開發提出了新的要求。Ruby，以及Ruby所代表的一類動態的、自由的程序設計語言和開發思想已經迎來了它們的時代，它們將和其他的科技一起，在下一個輪回中改變我們的工作，改變我們的生活，改變我們的觀念，直到下下個輪回將它們掃進歷史的功勞簿中為止。
所以，該放下的時候，就勇敢地放下吧。當然，如果想再跟發展大勢打一打，那就打一打，反正在技術進步的路上，保守的一方終究是要被解決的。
http://tech.csai.cn/sa/200608111524241005.htm
構架師（Architecture）是目前很多軟件企業最急需的人才，也是一個軟件企業中薪水最高的技術人才。換句話說，構架師是企業的人力資本，與人力資源相比其能夠通過構架、創新使企業獲得新的產品、新的市場和新的技術體系。那么什么是構架師、構架師的作用、如何定位一個構架師和如何成為一個構架師呢？這是許多企業、許多程序員朋友希望知道的或希望參與討論的話題內容。
我在此拋磚引玉，就上述幾個問題把我的體會和理解做簡單闡述。
所謂構架師通俗的說就是設計師、畫圖員、結構設計者，這些定義范疇主要用在建筑學上很容易理解。小時候到河中玩耍，經常干的事就是造橋，步驟如下：1、在沙灘上畫圖；2、選擇形狀好看、大小適合的石頭；3、搭建拱橋。其中我們挑出來畫圖的那位光PP小孩就是傳說中的 “構架師”了。
在軟件工程中，構架師的作用在于三方面：1、行業應用構架，行業構架師往往是行業專家，了解行業應用需求，其構架行為主要是將需求進行合理分析布局到應用模型中去，偏向于應用功能布局；2、應用系統技術體系構架，技術構架師往往是技術高手中的高手，掌握各類技術體系結構、掌握應用設計模式，其構架行為考慮軟件系統的高效性、復用性、安全性、可維護性、靈活性、跨平臺性等；3、規范構架師是通過多年磨礪或常年苦思頓悟后把某一類構架抽象成一套構架規范，當然也有專門研究規范而培養的規范構架師。他們的產物往往也分為應用規范和技術規范兩類。
與建筑學類似，如果軟件系統沒有一個好的構架是不可能成為成功的軟件系統的。沒有圖紙的建筑工地、沒有設計的造橋工程都是不可以想象的混亂世界。建筑工程如是，軟件工程中亦然！
由于國內合格、勝任的軟件構架師極為少見，直接導致了我國民族軟件產業水平的落后。在未來以信息產業為主導的社會，信息產業水平的低下將直接影響國家核心競爭力。究其原因，無企業非急功近利、個人缺乏引導。
企業的急功近利是有無法克服的原因的，那就是社會發展總體水平。“生存是第一位的，賺錢是第一位的”，多年來許多客戶抱怨國內的軟件公司無法信任、系統項目累做累敗、公司越換越差，但因國外不可能給中國做應用系統項目還不得不找國內軟件公司做。由于人月費用低、公司開發成本高，軟件企業對于應用只能草草了事，拿錢走人（很多公司拿不到后期尾款）。這樣的環境下，企業幾乎無法投入更多資源培養自己的構架師，加上眼花繚亂的跳槽風氣企業更是不愿投入……
那么要成為構架師的途徑似乎只有現在較為流行的軟件學院和個人自我培養了。關于軟件學院我接觸過不少，其宗旨絕大部分都是造就（or打造）企業需要的軟件構架師（or程序員or人才）。教師來源與企業、學員來源與企業、人才輸送到企業是他們辦學的手段。盡管各個如雨后春筍般出現的軟件口號差不多，但除了中科院、清華、北大等大院?？梢韵嘈乓恍┲猓峙赂嗟木褪菫榱巳﹀X賣學位了事……我有個朋友二十幾個人的小公司也想搞軟件學院：）
構架師不是通過理論學習可以搞出來的，不過不學習相關知識那肯定是不行的。參考軟件企業構架師需求、結合北京網暢公司構架師培養計劃以及目前構架師所需知識，我總結構架師自我培養過程大致如下僅供參考：
1、構架師胚胎（程序員）學習的知識是語言基礎、設計基礎、通信基礎等，應該在大學完成，內容包括 ：java、c、c++、uml、RUP、XML、socket通信（通信協議）——學習搭建應用系統所必須的原材料。
2、構架師萌芽（高級程序員）學習分布式系統、組建等內容，可以在大學或第一年工作時間接觸，包括 ：分布式系統原理、ejb、corba、com/com+、webservice（研究生可以研究網絡計算機、高性能并發處理等內容）
3、構架師幼苗（設計師）應該在掌握上述基礎之上，結合實際項目經驗，透徹領會應用設計模式，內容包括：設計模式（c++版本、java版本）、ejb設計模式、J2EE構架、UDDI、軟件設計模式等。在此期間，最好能夠了解軟件工程在實際項目中的應用以及小組開發、團隊管理。
4、軟件構架師的正是成型在于機遇、個人努力和天賦
軟件構架師其實是一種職位，但一個程序員在充分掌握軟構架師所需的基本技能后，如何得到這樣的機會、如何利用所掌握的技能進行應用的合理構架、如何不斷的抽象和歸納自己的構架模式、如何深入行業成為能夠勝任分析、構架為一體的精英人才這可不是每個人都能夠遇上的餡餅……
然而學海無涯，精力有限，個人如何能夠很快將這些所謂的構架師知識掌握？這是秘密，每個人都有自己的獨門家傳秘笈就不敢一一暴露了。不過有一點就是廣泛學習的基礎之上一定要根據個人興趣、從事領域確定一條自己的主線來努力