目前日期文章:200609 (3)

瀏覽方式: 標題列表 簡短摘要

此篇文章將放一些個人的ASP.NET所需要,但又不好搜尋到的語法。

kenlai 發表在 痞客邦 PIXNET 留言(0) 人氣()

上個星期剛參加完微軟的大拜拜---Tech Ed  Taiwan 2006,對於日漸演進的各種不同的 framework,以及越來越方便的 IDE(Integrated Development Environment) Tool + .Net 2.0 感到無限的讚嘆,只能說未來寫程式的人真是越來越幸福了!! 



而這樣的感覺卻不是多數人的想法,光某天 TechEd 的兩門課的講師,就同時提到了前一天對談時,有人問道,以後開發程式越來越容易,那我們程式設計師要幹嘛?程式開發人員個個感到威脅,覺得以後飯碗不保;在下的一位同事在參加完某天的Tech Ed之後,也是有如斯之感,可以想見,面對越來越方便的開發方式,有多少開發人員感到恐懼!! 



在下發現有為數不少的人在開發程式或系統時,有著錯誤的概念:不知道其「目的」為何,而把「方法」或「功能」當成了目的;這樣的思考,當然就打不到靶心,就不會命中目標、完成任務;軟體系統的存在是用來解決問題、改善問題或效率的,而不是為程式而程式、為系統而系統,所以最近的SOA(Service-Oriented Architecture)所討論的概念,個人認為才是軟體系統的開發人員所要著重的課題。(而我這個軟體業的freshman,當然更需要在這塊領域多加學習)



以下這篇文章,為個人很喜歡的電腦書作者--董大偉 先生所寫,對於前述的疑問,有著很讓我認同的想法。



不過文末的幾句話,真是說到我心坎裡了,有時候真的覺得軟體業的人蠻可憐的,常常覺得時間不是自己的,都時間賣給公司的感覺,常讓人有錯覺,不知是為了生活而工作,還是為了工作而生活了,如果說未來的開發速度越來越快,我衷心希望多出來的時間可以做做自己、玩玩興趣、陪陪家人...等等這種應該要去重視的事,而不是將節省下來的時間投入更多的專案、更多的工作。(以我對台灣人"勤奮"工作以及老闆們念茲在茲的認知,很可能是走向最後一個方向.....)



《延伸閱讀》

1.SOA, Service-Oriented Architecture (from WIKI)

2.Tech Ed Taiwan 2006



--

被ASP.NET 2.0搶走飯碗的Programmer?   (by 董大偉)  

原文出處:book.studyhost.com



  VS2005已經正式推出,很多人都看過ASP.NET 2.0的華麗外表!那些可以自由在頁面上拖曳的WebPart,可以套用版型的MasterPage,可以為頁面穿戴炫華麗衣裳的Theme和skin...。不只如此,大幅節省程式碼的登入控制項群組(包含完整的Forms認證機制、MemberShip和Role類別),把過去UI(使用者介面)和資料庫存取機制徹底簡化的資料存取控制項(DataSource、和xxxxView字尾的超強控制項),這些東西讓頁面上的表單維護(master-Detail或電子表單)機制變的幾乎不用寫程式。


  再加上VS2005對開發環境的大幅改善(SmartTag、程式碼片段、到處都出現的精靈...),總之,開發人員需要作的事情相對的減少,很多朋友看到之後,第一個問題都是,那...以後程式設計師要做什麼???會不會一堆初學者,做出來的網站,都要比累積了很多年的開發老手來的好?難道,很多人就這樣要失業了嗎?或者,又得要放棄才剛學好的ASP.NET 1.1,重新投入2.0的懷抱?(知道嗎?很多公司才剛擬定從ASP轉換到ASP.NET的計劃...)


  現在台灣市場上,還有為數不少的產品都以ASP來開發,過去在筆者很『熱心的推廣』ASP.NET 1.1的那個時代,已經討論過這個問題。當您(ASP開發人員),看到其他剛畢業的年輕小夥子,隨手寫出的系統,都比自己用ASP開發了三天三夜的功能還強,這時候情何以堪?這個問題,到了ASP.NET 2.0將會更加明顯。過去ASP.NET 1.1要開發很久(甚至做不出來)的功能,現在到了ASP.NET 2.0很可能已經是基本功能了!相較之下,ASP與ASP.NET 2.0之間的差異則是月來越大,因此對於在業界開發的朋友們,相信很多人早已經自動歸入轉換的跑道了...


  另外則是採用ASP.NET 1.1作為專案開發的人員(類似筆者這種)。過去我們花了很多心思從ASP轉換到ASP.NET 1.1,沒想到在ASP.NET 1.1才辛苦開發完成的函式庫,到了ASP.NET 2.0後,某些變成基本功能,我要說,心裡除了很X之外,實在也有點佩服微軟,畢竟這是一種進步,過去ASP.NET 1.1上要花長時間才能完成的東西,現在微軟則幫你做好擺在眼前等你享用...


  有人會說,ASP.NET 2.0這樣的改版,讓很多開發人員越來越不知道系統內部的運作...,我要說的則是,現在很多開發人員,其實從很早以前就已經不知道系統內部的運作了,現在的問題是,開發人員目前所扮演的角色以及他究竟該不該知道系統內部的運作?


  從不知道什麼時代開始,很多從事軟體開發的社會新鮮人,早已經不知道(也不需要知道)DOS的存在(和它輝煌歷史),也不知道0與1的意義,但是他們開始會物件導向,開始知道SOA架構,可是卻從沒寫過Client-Server的程式,他們生來系統就已經是那個樣子,程式在Web上面跑的很自然,至於瀏覽器怎麼處理HTML,IIS怎麼處理CodeBehind程式碼,他都覺得這應該不是他的問題...


  如果你對照ASP.NET 2.0的很多功能,你會發現這個現象異常明顯,從很多角度來看ASP.NET 2.0+VS2005這樣的組合,已經有點像『整合了程式產生器的程式語言』,而新增的很多炫麗套件,則根本有點像是網路上的網站樣板或是模組...,不知道這個現象是否是微軟衝著網路上越來越多的免費資源而來,但是不可否認的,這樣的組合,確實會為很多初階開發人員節省不少時間。


  回到前面的那個問題,當我們討論到這樣的改變對於程式設計師來說,究竟好不好?筆者除了建議採用其他開發工具(ASP、JSP、PHP...)程式設計師,一定要花點時間來了解ASP.NET 2.0之外(根據筆者的經驗,同時會去涉獵兩種以上開發工具的人真的不多...),也建議從ASP或是ASP.NET 1.1轉換到ASP.NET 2.0的開發人員必須深思一個問題:『你認為自己未來的角色是什麼?』(是寫程式的人?還是開發系統的人?)


  根據不知道哪裡的DM,據稱ASP.NET 2.0開發一套系統,比ASP.NET 1.1約減少70%的程式碼,有沒有很誇張?筆者要說,根據我自己測試的結果,雖然不敢說到70%,但是節省的時間絕對超過一半!


  一半!一半的意思是什麼?一半的意思是,過去老闆要請兩個人,現在只需要請一個!那理論上,ASP.NET 2.0的開發人員應該要比ASP.NET 1.1或ASP要值錢一點,但是,以後當大家都使用這個開發工具,那還玩什麼?我要說的是,程式設計師要注意自己的『Value』!


  我們回憶一下,當開發一套系統的時候,開發人員花了多少的時間在做商業核心的部分?我們所謂的核心,不是資料庫的基本存取、不是畫面的調整與呈現、不是那些寫過一次之後,另外一隻程式只需要小改一下就可以用了的部分。而是這套系統的核心,例如MRP的物料相關運算,例如CRM的客戶評等運算...等。一套系統裡面,一定有一些商業邏輯,是這個系統裡面最重要的部分,是這個系統要達成的『目的』,其他的環節則都是配合著這個『目的』而來的。資料庫,只是為了存放資料,UI,只是為了讓使用者有個操作環境...,這些其他的東西不是不重要,而是因為模式固定,所以開發的成本越低越好(也就是花的時間和錢越少越好)!


  從ASP到ASP.NET 2.0的轉變就是這樣(事實上所有開發工具的改版目的都是這樣,從Windows到Java亦是,從VB到VB.NET又何嘗不是!),請不要忘記,開發一套系統的目的不是要來『讓程式設計師寫程式』,開發一套系統的目的是要來『解決一個問題』。因此系統的重點是能否解決問題,而不是這套系統宣稱花了幾萬個工時,內含幾千隻程式,包含上百個模組...。一個CRM系統畫面做的再漂亮,記憶體使用再精簡,資料庫運算再迅速,找出的目標客戶永遠無效(不購買)那要系統又有何用?


  時至今日,開發工具已經可以為我們節省絕大部分的時間(特別是花在與程式核心運算無關的開發時間),因此我們回顧從ASP到ASP.NET 2.0,我們越來越不需要花時間在調整UI、在寫前端JavaScript、版型和版面可以透過MasterPage和Theme快速完成,資料庫存取可以利用DataSource大幅減少程式碼,WebPart可以幫助我們迅速做出一個炫麗的Portal,Login控制項可以讓我們使用現成的會員管理機制...這一切的一切,都只有一個目的,縮短開發人員花在系統『非核心程式碼』的開發時間。


  整個物件導向程式設計的目的也是,希望程式碼『可重用』,縮短開發時程,讓開發人員專注在開發系統的核心,最理想的狀況或許是,開發人員不要管與系統核心無關的程式,而多花點時間在核心的運算邏輯。回顧一些專案,您會發現,很多時候我們花在『主要目的』的時間遠低於『次要目的』 。舉例來說,一套薪資處理系統,計算薪資的程式碼數量(核心功能),遠低於系統內『產生報表、資料庫存取、使用者介面的調整和控制』(次要功能)的程式碼數量。當然,這些附屬或次要功能不是不重要(當產品的主要功能沒啥特色,人人都可以開發的時候,就會開始比較次要功能,例如我比其他競爭對手多了兩支報表~~哪怕這兩支報表一年只用一次,也會變成產品『特色』),但是別忘記,從過去的例子我們可以發現,一套系統能構脫穎而出,絕大部分的原因都不是因為次要功能特別強,而是主要功能與眾不同。


  也因此,開發工具一直在致力做一件事情(事實上,整個軟體工程也一直在做這件事情),就是讓開發人員花少一點時間在次要功能上,而能夠把省下來的時間,多開發(或研發)一些具有真正價值或與眾不同的主要功能!可能是更強的運算邏輯、更搶眼的創意、更體貼的設計...等。至於只需要花苦工就可以完成的部分,還是交給開發工具(或程式產生器)吧。ASP.NET 2.0所有的新功能,幾乎都是針對這些部分而來,我們期待開發人員,能夠把省下來的時間,投資在更有創意和價值的事情上。


  甚至,哪怕是把省下來的時間花在多陪陪家人都好~老實說,在台灣寫程式其實真的挺辛苦的,賺的錢不多,工時卻很長,又不受重視,也因此開發人員自我價值的提昇和成長,是很重要的,如果新開發工具的出現,能夠有效的節省我們的時間,那是令人興奮的,但若開發工具的出現,卻取代了你的價值,則是令人感到遺憾的,學習和成長,加上一點點的創意,依舊是奠定自己不變價值的基礎。














-----

kenlai 發表在 痞客邦 PIXNET 留言(0) 人氣()

(網路的轉寄信,如有人知道出處或作者,請告知,在下立即改正,謝謝。)



FW:人家培養的是能力,而我們灌輸的是知識



我兒子正在讀高二,考了一道歷史題:成吉思汗的繼承人窩闊臺,公元哪一年死?最遠打到哪裏?第二個答案兒子答不出來,我幫他查找資料,所以到現在我都記得,是

打到現在的匈牙利附近。



一次偶然的機會,我發現美國世界史這道題目不是這樣考的。它的題目是這樣的:成吉思汗的繼承人窩闊臺,當初如果沒有死,歐洲會發生什麼變化?試從經濟、政治、社會三方面分析-



有個學生是這樣回答的:這位蒙古領導人如果當初沒有死,那麼可怕的黑死病就不會被帶到歐洲去,後來才知道那個東西是老鼠身上的跳蚤引起的鼠疫。但是六百多年前,黑死病在歐洲猖獗的時候,誰曉得這個叫做鼠疫。如果沒有黑死病,神父跟修女就不會死亡。神父跟修女如果沒有死亡,就不會懷疑上帝的存在。如果沒有懷疑上帝的存在,就不會有意大利弗羅倫斯的文藝復興。如果沒有文藝復興,西班牙、南歐就不會強大,西班牙無敵艦隊就不可能建立。如果西班牙不夠強大,意大利不夠強大,盎格魯─撒克遜,會提早200年強大,日耳曼會控制中歐,奧匈帝國就不可能存在。



教師一看,說:棒,分析得好。但他們沒有分數,只有等級,A!



其實這種題目老師是沒有標準答案的,可是大家都要思考。





不久前,我去了趟日本,日本總是同我們在歷史問題上產生糾葛,所以我在日本很注意高中生的教科書。他們的教師給高中生布置了這樣一道題:日本跟中國100年打一次仗,19世紀打了日清戰爭(我們叫甲午戰爭),20世紀打了一場日中戰爭(我們叫做抗日戰爭),21世紀如果日本跟中國開火,你認為大概是什麼時候?可能的遠因和近因在哪裏?如果日本贏了,是贏在什麼地方?輸了是輸在什麼條件上?分析之-



其中有個高中生是這樣分析的:我們跟中國很可能在臺灣回到中國以後,有一場激戰。臺灣如果回到中國,中國會把基隆與高雄封鎖,臺灣海峽就會變成中國的內海,我們的油輪就統統走右邊,走基隆和高雄的右邊。這樣,會增加日本的運油成本。我們的石油從波斯灣出來跨過印度洋,穿過馬六甲海峽,上中國南海,跨臺灣海峽進東海,到日本海,這是石油生命線,中國政府如果把臺灣海峽封鎖起來,我們的貨輪一定要從那裏經過,我們的主力艦和驅逐艦就會出動,中國海軍一看到日本出兵,馬上就會上場,那就打!按照判斷,公元2015 年至2020年之間,這場戰爭可能爆發。所以,我們現在就要做對華抗戰的準備。



我看其他學生的判斷,也都是中國跟日本的磨擦,會從東海開始,從臺灣海峽開始,時間判斷是2015年至2020年之間。



這種題目和答案都太可怕了。撇開政治因素來看這道題,我們的歷史教育就很有問題。翻開我們的教科書,題目是這樣出的:甲午戰爭是哪一年爆發的?簽訂的叫什麼條約?割讓多少土地?賠償多少銀兩?每個學生都努力做答案。



結果我們一天到晚研究什麼時候割讓遼東半島,什麼時候丟了臺灣、澎湖、賠償二萬萬銀兩,1894年爆發甲午戰爭,1895年簽訂?馬關條約?背得滾瓜爛熟,都是一大堆枯燥無味的數字。



那又怎麼樣,反正都賠了嘛!銀兩都給了嘛!最主要的是將來可能會怎樣!



人家培養的是能力,而我們灌輸的是知識。



天啊!不能完全責怪孩子,應該反省的是我們大人。














-----

kenlai 發表在 痞客邦 PIXNET 留言(2) 人氣()