Category: 軟體開發


if you get this error, it’s because Sliverlight assembly is not in GAC. Do this to fix:


cd C:\Program Files\Microsoft Silverlight\4.0.50524.0
gacutil -i System.Core.dll
gacutil -i system.dll
gacutil -i system.net.dll
gacutil -i system.xml.dll
gacutil -i System.Runtime.Serialization.dll

check out what other people said.

廣告

If you get something like this:

Server Error in '/applicationname' Application.
---------------------------------------------------------------------------
Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Requested registry access is not allowed.

Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:
[SecurityException: Requested registry access is not allowed.]
Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) +473
....

I’m not sure there’s a secured way, but adding permission for iis daemon user solve the problem for me.

1. Find out which deamon user your app is using, by looking up App_Pool and secruity section in event log.

2. Give the user permission to read/write access for the eventlog registry entry. To do so, open regedit and navigate to the key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog

.
Right click and select Permissions, and add permission for the user.

3. restart iis and give it a try.

Mastering the VI editor

http://rcm.amazon.com/e/cm?t=mingster-20&o=1&p=8&l=bpl&asins=1565924975&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifrGood basic – http://www.eng.hawaii.edu/Tutor/vi.html
Download PDF version here

Check out this SlideShare Presentation:

mingster.com

check out my main site at mingster.com

This is good intro in Chinese about XP programming. Finally there’s more talk in Taiwan about iton a major IT publication.

If you interested in xp, also check out my older post. You should also know about Aglie Programming.
文/李延華 (記者) 2007-09-02

極限編程:訴求擁抱改變、注重溝通與測試,適合小團隊開發的敏捷開發方法論
在軟體開發領域談到「XP」,可不是指Windows XP,而是eXtreme Programming(極限編程)。

落實XP方法論的第一步,是拿起扳手與螺絲起子,拆除辦公室的隔板。因為XP強調的4個價值觀──溝通(Communication)、簡單(Simplicity)、回饋(Feedback)與勇氣(Courage),重點就是希望建立暢通而有效率的溝通管道。

另有12項實務,包括客戶駐廠(On-Site Customer)、系統隱喻(System Metaphor)、程式共享(Collective Ownership)、重構(Refactoring)、搭檔編程(Pair Programming)、編程標準(Coding Standards)簡單設計(Simple Design)、測試先行(Test Before Coding)、通盤規畫(The Planing Game)、小型改版(Small Release)、持續整合(Continuous Integration)、四十工時(Forty-Hour Week)等。

XP的簡單設計與靈活因應需求改變的主張,吸引所有人的目光,不過,我們不能忽略測試驅動(Test Driven)這個重要的原則。「測試」在XP中是必要的條件。

由於需求是不斷改變的,所以XP建議擁抱改變。而測試案例的目的,就是為了因應改變,而建置健全的測試案例將使專案無懼改變。

此外,不是所有的專案都適合XP,它適合2~12人的開發團隊,特別是應用在需求經常改變的領域。管理者、客戶及開發人員對XP而言,都是專案的成員,必須透過充分的溝通與回饋,才能讓每個成員都了解目前的版本能否滿足需求。文⊙李延華

Iteration 往覆式開發方法
早期的開發方式通常是瀑布式(Waterfall),從分析、設計、實作、測試到交付,是一路到底、不可逆的過程,然而這種方法在軟體業卻存有很大的風險。

由於客戶的需求經常改變,而且開發者憑自己的想像所開發的系統,也未必符合客戶的期望,因此許多方法論改採往覆式開發,每次設計、實作、測試與交付都採最小規模的方式。若不符客戶需求的設計,便可即早發現,進而修正。

Feedback 回饋
回饋與往覆是息息相關、互為因果的事件。在XP中,客戶與開發團隊之間的互動決定專案的成敗,客戶的回饋能提供專案後續發展的寶貴訊息。

在12項實務中,「客戶駐廠」也是呼應「回饋」的做法,而這個價值觀點出在XP方法論中客戶對專案的重要性。因為藉由客戶即時的回饋,開發團隊可以盡早了解問題與風險所在,即時修正不符合客戶預期的設計,朝正確的方向發展。

Simplicity 簡單
以瀑布式的開發方式為例,在實作系統之前,必須先做好完整的需求分析與系統設計。而且技術人員為了讓系統保持最大的彈性,往往在架構上預留擴充的空間。

但是XP方法論認為,客戶的需求隨時在改變,而且環境與技術也不斷地更新,所以預留彈性反而是增加包袱,因此建議開發者盡可能保持符合需求的最簡單版本,不要預想未來可能的功能,以控制成本、降低風險。

System Metaphor 系統隱喻
在XP中,每個人同時扮演系統分析師、系統設計師和程式開發者的角色,藉由客戶駐點,面對面溝通的方式,取得第一手的需求,然後直接做給客戶看。

為確保彼此的溝通沒有誤解,因此必須善用隱喻,讓客戶與開發者有共通的語言,利用說故事和打比方的方式,取代冗長而難以理解的文件。比喻的用語可以與IT無關,盡量以易於了解的方式,表達需要的功能。

Pair Programming 搭檔編程
兩個人共同開發一隻程式,一個人在寫程式的時候,另一個人需負責看程式,以檢查是否有出錯或可改進的部分,而且兩人要經常互換角色。

不過,搭檔編程通常是XP各項實務中最難被主管接受的一項,因為從成本與效率的觀點出發,大家各寫各的程式,將有兩倍的工作效率。再加上,管理者不容易確保看程式的人工作的品質,無法得知他是在發呆還是認真檢視程式碼。

Collective Ownership 程式共享
搭檔編程還有進階應用,就是搭檔關係也要經常替換(Switch Pair)。當使用者提出新的需求時,開發者就會被分配與新的對象合作,一起修改其他人合作開發的部分,並加入新的功能。

團隊的每個成員都有機會轉換與不同的對象搭檔,合作開發系統的各個部分,所以所有人也就都有能力修改與維護系統的每個部分,這樣的做法即是「程式共享」。

Continuous Integration 持續整合
在開發期間,當一組搭檔共同完成一個使用案例(User Story),並通過單元測試過後,便可以將程式簽入集中管理的版本控管系統,重新建構一次系統,並諮詢其他搭檔,執行所有測試。採用XP方法論一天內可能建構系統好幾次。

系統整合與測試之後,經由測試執行結果,可以讓開發團隊與駐點的客戶了解系統現階段確實可執行的功能是否符合需求,並掌握開發的進度。

Small Release 小型改版
依照XP的方法論,通常開發團隊是依據Story Card切割工作。每完成一個Story Card,就發行最新、可執行的版本,交由客戶驗收。此即XP所謂的「小型改版」。

客戶如果頻繁地檢視最新版的系統,便可確認專案是否符合期望,然後回饋意見作為開發團隊持續改進的參考。依照XP的要求,開發團隊至少每3周就要重新整合新功能到產品中,發行新版本,交由客戶驗收,並檢視未完成的需求。

Refactoring 重構
重構的意思,是指在不改變程式碼的外部行為的情況之下,修改程式碼,以改善內部的一致性和清晰性。根據XP的方法論,在每個小階段發行以及每個往覆式的周期之後,甚至是每天下班前,都可以執行一次重構。

重構通常是透過開發工具輔助執行,一般不會影響程式執行的結果,但為了確保重構之後,不會改變程式碼的行為及影響功能的正確性,開發團隊必須齊備完善的測試機制。

http://blog.darkthread.net/blogs/darkthreadtw/archive/2007/06/30/developers-are-you-underpaid-or-overpaid.aspx

Developers, Are You Underpaid Or Overpaid?
Phil Haack寫了一篇探討開發人員產能差異的好文章。可能是因為自己瘋狂熱愛Coding,一直以來對許多客戶、專案經理、公司主管貶低開發人員價值的錯誤認知頗不以為然,於是,這類的文章讀來格外心有戚戚焉。

對開發人員的種種誤解中,我最痛恨的是以下幾種:

1) 為什麼寫一個線上購物網站要花五十萬? 我小姨子的同事唸高中的兒子說給他五萬元就可以搞一個!

2) 每年多少資管畢業生呀? 程式開發人員去街上抓就一大把,還怕找不到人?

3) 不過就寫程式唄! 找誰來寫還不都一樣? 你專案不是缺人,為什麼不叫隔壁組現在沒事的老王加入你的Team? (Darkthread定律: 連砸了三個案子的人,在撐著不離職前都會很涼)

4) 當黑手寫程式有什麼前途? 把系統分析做好,外包給老印、老中的Programmer才是王道! 別把時間花在這種低層次的工作上

read on…….

情感的設計

這幾年來,設計變成了一門顯學。不論是哪個產業,都開始強調設計的重要性。

看看這期IDEO公司的這篇文章,你會發現,設計絕對不像我們刻板印象中所想的一樣,只是視覺或美感的層次而已。

對全球設計界首屈一指的企業IDEO來說,設計是在為使用者解決背後隱藏的問題。這家公司創立十五年來,美國商業週刊的年度產品設計獎首獎,年年都由它包辦。

它把設計的重點從創造產品,擴大到創造經驗上。例如,美國一家醫院希望藉由它的協助,找出節省成本、吸引病患的方法。原來以為可能會需要改建新大樓、配備新科技設備,沒有想到,IDEO帶領醫院工作人員深入觀察病患看病流程後發現,只重新設計病人掛號流程,更新候診室,就能收到很大的成效。

因為要把設計從創造產品擴大到創造經驗,因此IDEO刻意聘用背景多元的員工,設計團隊包含設計師、工程師、心理學家、人類學家等。

在設計的過程中,IDEO所依靠的絕對不只是創意和靈感,還包含更多科學的流程和紀律。例如,它有嚴密的五個步驟,第一個步驟就是好好觀察顧客使用產品的經驗,甚至自己變成顧客。第二個步驟是腦力激盪:它嚴格要求參加的人不能說,「這點子不錯,『但是』……」;而要說「這點子不錯,『還有』……」。

某個程度來說,IDEO已經不是一家設計公司,而是一家管理顧問公司,它所做的很多事情,都是在幫助企業改變思維模式(EMBA雜誌第237期第六八頁)。

關於改變,是另外一門很大的學問。

在公司裡,不論是導入一個資訊系統,或推出一個人力資源方案,往往都會遭遇很大的抗拒。有經驗的經理人都知道,不順利是常態,能夠順利推動,才是奇怪的事情。在變革行動的中期,阻力往往也特別大,也就是當開場的鑼鼓喧天熱度降低,員工開始精神不濟、注意力渙散的時候。

要怎樣才能讓「改變」不偏離軌道,變革之火不熄滅呢?管理顧問Eric Beaudan提醒我們,這個時候,要重新思考變革的目標和期望,並且改變速度。

例如,也許你的變革速度太慢,讓人不耐,或者恰恰相反,你速度太快,讓人員跟不上。此外,也許你必須設法添加刺激,或者創造危機,讓人們重新把注意力投注在這個變革行動上(EMBA雜誌第237期第三六頁)。

畢竟,就像IDEO創辦人凱利所說:「設計代表的是產品的情感層次。」變革處理的,又何嘗不是人的感情層次?

版本控制系統不祇可以幫助妳追蹤修訂手上的工作進度,讓妳在千鈞一髮之際還能拾回過往辛苦的結晶,甚至能夠讓妳跟其他人協同工作、合作無間。

一般人聽到「版本控制系統 (Version Control System, VCS) 」或者「修訂版控制系統 (Revision Control System, RCS) 」,總會覺得那是寫程式的怪物們纔會去用的東西、祇有程式碼纔會被放在那樣的環境裡開發。然而隨著資訊量持續增加,每個人在日常生活中必須要掌握、處理的的資訊也越來越繁雜,不管是為了做專題、報告、寫論文乃至於翻譯等,祇要是長時間持續產出的工作,也都逐漸需要有版本管理系統的協助,纔能夠事半功倍了。…..

c#程式碼編寫標準

誰都會寫程式碼!幾個月的編程經驗可以讓你寫出「可運行的應用程式」。但在開發團隊的運行模式下,以最有效率的方式編碼、能被小組成員順暢承接的程式碼就必需要下更多的功夫!

要知道,大多數程式設計師在寫「可運行程式碼」,而不是「高效率程式碼」。寫高效程式碼是一項藝術,必須靠紀律及學習來實踐。建立一個高效率、有默契的開發團隊更需有一定的規範及標準流程。

想要讓開發出來的程式碼穩固且容易維護,除了有必要適當地採用設計模式 (Design Patterns) 之外,也有必要採用編碼原則 (Coding Guidelines),做為寫程式時依循的準則。設計模式是在設計階段進行的,主要由系統設計者 (System Designer)負責,所以和程式員的關係比較不是那麼密切。至於編碼方針,就和程式員的關係相當密切了。

程式碼命名及格式規範的目的為建立開發團隊的默契以及效率。檢視一篇與自己撰寫風格相同的程式碼不但能減少無謂的猜測,也能快速暸解程式碼,立即進入程式撰寫的狀況。

輔助工具
在Google搜尋keyword :: “Code formatter, code beautifier",你可找到一票自動化的輔助工具。對C#來說,最重要的編程方針是美國微軟MSDN網站上的Design Guidelines for Class Library DevelopersreSharper則是目前我們使用的自動化工具。