顯示具有 工作 標籤的文章。 顯示所有文章
顯示具有 工作 標籤的文章。 顯示所有文章

2010年1月4日 星期一

SVN目錄移除方式

如果希望將原本 svn 的目錄內所有 .svn 的管理資訊目錄移除,在 Windows 底下可以直接用以下語法在 DOS 視窗執行移除

cd <預計移除目錄>
for /f "usebackq" %d in (`"dir *.svn /ad/b/s"`) do rd /s/q "%d"

參考網頁

另外,若SVN目錄改以 "_svn" 命名,請修改上面命令列內容。

2009年11月9日 星期一

M$的VSTS(Visual Studio Team System)

以下內容轉載自 Kai's World 微軟的VSTS(Visual Studio Team System)能有多少發揮呢?
最近公司要打算導入VSTS把IT的某個開發Team拿來當白老鼠,基於一些理由我也就需要研究一下VSTS在玩什麼把戲

看完一些他的教學文件跟產品介紹文件,我其實是非常同意他的遠見,他是想做一個系統開發平台,建立一個Team Foundation Server然後不管是開發人員、架構師、測試人員、DBA、Project Manager通通在同一個平台做事,然後他再提供各個專業人員所需要得工具,讓大家協同合作,還有內建的一些軟工的流程可以套用,落實開發流程,進一步自動產生一些有用的報告或是"Real"的報告讓Project Manager真正掌握開發進度。

我想以上是他想要完成的目標,再細部的往下研究一下

VSTS他並非使用UML的語言而是DSL(Domain Specific Language),他提出的理由是UML太過抽象,是否可以應用在不同的Domain,我們是不是應該因應不同的Domain有不同的語言,所以DSL還有提供讓你定義你自己的DSL,他也提出了一些學術上的論點,找來當初制定UML的人來幫他背書。

我沒用過DSL也沒有裝來畫畫看,所以我無法評論,但是我想很多人會有跟我一樣的想法"搞什麼又要來一個規格之爭嗎"好不容易花時間學會了UML,結果你要我用你自己定義的DSL,我又要花時間學DSL,然後只For你的VSTS,這樣實在是!@#$%^&*(這也是我沒裝來畫畫看的原因),不知道是不是我有所誤會,說不定是共存,讓想用UML的用UML,想用DSL的用DSL這樣比較make sense如果是強迫中獎這樣我想很多人都很難接受。

接下來分享的部份是我認為比較有價值的部份"軟體工程"

我相信在軟工的世界沒有什麼Best Practice,所以目前才有這麼多派系之分,不同公司、不同文化、不同案子都可能產生公司自己的Best Practice,這次微軟提供了微軟自己的MSF(Microsoft Solutions Framework)你可以用微軟開發軟體的方法論來開發自己的軟體,微軟也號稱這套方法論在微軟內部已經從1994年使用自今(不知道大家覺得微軟的品質如何)這MSF涵蓋了CMMI Level3也讓你對未來Level4、Level5做準備。

如果只是這樣我想大家會問他跟RUP沒什麼兩樣阿

重點來了我覺得最吸引人的有兩點

1.他也讓Agile同時存在,在Anile部分他提供了MSF for Agile Software Development微軟從Motorola找來Agile社群中的David Anderson來操刀,讓兩種方法論都可以在VSTS上使用,但是這還不是最新引人的,最吸引人的是你可以客製化你的流程,他只是提供你最極端的兩個範本,你可以依據自己組織的需要調整你自己的開發流程,微軟也宣稱會繼續update各大學派的方法論範本給大家下載免費使用(當然VSTS是要錢的)。

2.文件管理部份由於VSTS是系統協同合作的,很多報告可以由系統自動產生,讓不愛寫文件的工程師工作量減輕不少(我也不愛寫但是有時又是非寫不可),再者我之前提到的"Real",很多人都有經驗明明,你手上的程式只完成30%,但是project schedule是50%,你在report中要寫多少 ? maybe 40%,也或許你認為後面的開發速度會突飛猛進cover現在的delay而填上50%,導致Project manager拿到錯誤的資料,而做出錯誤的評估,你也浪費時間寫出一份讓人有錯誤評估的report。

遇到這狀況,我還寧願不要有這份report,讓工程師專心寫程式。Project Manager透過Project manager的工具連上server,看看目前完成度或是直接選取所需要的資訊。

至於DBA,版本控管,還有測試方面市面上已經有很多工具,大致大同小異就不多做介紹,接下來就是讓市場跟時間來證明他了。
---------------------------------------------------------------------------

TFS 出了名的難裝~ 原本還想使用已經於VM既有的SQL 2008 DB,但似乎狀況更多,到頭來重作一份VM從頭來過,DB改用SQL 2005就順了~
安裝記實:
1.SQL Server Agent需啟動且為自動。
2.SQL Server Browser需啟動且為自動。
(到最後,整個SQL開頭的service都設自動且啟動!除了SQL Server Active Directory Helper外)
3.使用 SQL Server 介面區組態工具啟用遠端 TCP/IP 連接。
4.SQL 2005需上到 SP2。
終於,最後一個問題僅剩硬體需求,CPU需2.2G,就不理它繼續下一步,接下來的過程如同下述說明,建立TFSSERVICE帳戶啟動服務用 and keep Next 直到完成。
5.依個人喜好,可以依照"安裝指南",安裝"Team Foundation Build"。
6.再安裝"Team Explorer"。
7.安裝Windows SharePoint Services Extensions。
8.安裝TFS SP1。
這樣就全部裝好,接下來就打開 Visual Studio,使用Team總管連結上Server。
(2009/11/24)
裝是裝好了,但要開第一個專案就出問題了!!~ 一直出現錯誤
Error
無法連接到位於 192.168.XX.XX 的指定 SQL Server Reporting Services。

Explanation
[專案建立精靈] 無法連接到位於 192.168.XX.XX 的 SQL Server Reporting Services。此時尚無法判斷連接失敗的原因。由於連接失敗,精靈無法完成建立 SQL Server Reporting Services 網站。

(2009/11/25)
改參考 Huan-Lin 學習筆記 on DotBlogs 中的 Visual Studio Team Foundation Server 安裝筆記重裝整個TFS,這次選用SQL 2005 Ent版,並於SQL裝完上SP3後安裝WSS3.0 with SP2。
怎麼這次是被診斷沒安裝Analysis Service~ 天阿,心裡真是很X。
(2009/11/26)
幾經波折,被Firewall卡了一陣子,最後索性依照 install guid把所有port開啟(NOD32請切到互動過濾模式,不然都不知道它會不會亂濾!),原先仍一直被診斷沒安裝Analysis Service~ 試著merge TFS install image與sp1後重試還是一樣的訊息,期間改了多次service啟用帳戶,最後是都以TFSSERVICE啟動,後來似乎因為WSS沒啟用所致 -.- ,
終於~~只剩CPU或RAM不符要求,終於可以下一步了...
話說,要繼續TFS安裝時,在WSS一步又被卡了,訊息如下:
Error codes: TF220035 (The URL at the specified location is not a Windows SharePoint Services site) or TF220041 (The specified Windows SharePoint Services site URL is not the default site collection site)
這問題請見TFS 2008 on Windows Server 2008 Installation Problem (TF220035 or TF220041)又過了一關~~ 下一王是
Error 28805 Setup cannot finish the request to the SQL Server 2005 Reporting Service report server. Verify that the report server is installed and running, and that you have sufficient privledges to access it看來是Reporting Service的加密金鑰檔住~直接刪除!!又過了一關~~
挖塞~~已成功安裝~~~~~~(我哭了...)
看來,要開始安裝TFS前,需確認以下四個URL都要有:
http://btf-tfs/
http://localhost/reports/
http://btf-tfs:30736

參考來源:
鳥毅的Blog:安裝Team Foundation Server SP1 測試環境
VSTS 實驗室: TFS 2008 單一伺服器簡易安裝說明 (在「Google 網頁註解」中檢視)
Visual Studio Team Foundation Server 安裝筆記

2009年8月18日 星期二

面試系統分析設計的好題目

今天終於下定決心update面試考題,看過SAD方面有一篇很好的文章,轉仔原文如下。

(原文轉載自 克明老師Blog 從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇 )
如果我是某大軟體公司的主管,要應徵軟體結構性的設計人員 (偏對技術性,而非需求分析),一般的職稱是稱之為 系統設計師 (SD, System Designer),或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等,那麼,我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已,一點意義都沒有。 要背書的話,不如直接給個電腦上網,然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。
我會提供的考題,必然是針對應徵人員 "自我思考推理" 的能力驗證,答案的正確性完全不重要,重要的是你為什麼是這樣表達設計的,能否自圓其說。 具有獨立思考能力的設計師,這才是人才!
所以,我會提供一個如這樣的考題:

Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤,相對來說,一個標籤可以有一到多個書籤。 另外,標籤是不會含有子標籤 (Sub-Tag) 的。
如果我要改良 Google 書籤的設計,希望能再加上 "資料夾 (folder)" 的管理觀念,也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一),而某一個資料夾可以擁有一到多個書籤,同時資料夾也能再包含子資料夾 (Sub-folder)。
同樣類似的應用,可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。
請你利用 UML 類別圖,來表達出關於 書籤、標籤與資料夾的結構關係,並簡單說明你的設計想法。


上述的考題是一個 "需求陳述",應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述,那麼也可以再佐以範例,來解釋什麼是 書籤、標籤與資料夾的概念。
老實說,我是以為,這類的結構設計應該算是很基礎的了,事實上,答案也比想像得意外簡單。 但是,我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員,最直接給我的答案就是說: 這不就是 "複合結構 (composite structure)" 樣式的應用嗎? 不管你說什麼,反正先把設計圖畫出來再說吧。 結果呢,也真的如我所料,表達不出所以然,真的就只是在背書而已。 最大的盲點,就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起,而其實這兩個是一點關係都沒有的;甚至有些還執著在因為 標籤與書籤 的多對多關係,所以又拉出了一個所謂的 "關聯類別 (Association Class)",卻又說不所以然,越弄越複雜。 因為既然是表達想法,所以類別圖自然是表達 概念 (concept)與概念之間 的關係,而至於那個多對多的關聯類別,是在更細節性的規格設計實做階段再來討論即可,太早論及,反而模糊了要突顯的概念。
表達這類結構性的設計圖,要先找出核心的類別是什麼。 在本例中, "書籤 (bookmark)" 即為本文主體,是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連,而是各自與 書籤 建立關係,那麼,這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖:

這張設計圖該如何解讀呢?
先觀察紅色區塊,也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看,它可以被多個 標籤 標記,所以在多重性 (multiplicity)的表達,會是 1..* (一到多)。 再來從 標籤 的角度來看,一個標籤可以有一到多個 書籤,所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題,大概知道意思就可以了。
再來就是觀察藍色區塊這邊,這就是典型的 "複合結構 (composite structure)" 樣式了,它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來,成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢? 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾,在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係,它必然被包含 (也就是聚合關係)在某一個 資料夾 內,所以在 資料夾 類別這邊的 多重性 是表達為 1;而一個 資料夾 可以有 一到多 個書籤與子資料夾,所以在 "Bookmark Entry" 類別這邊,多重性是表達為 1..* 。
說實在的,即使不會複合結構的表達也沒關係,若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別),這就夠了,在這個考題當中,反而要突顯的不會是資料夾的樹狀結構,再次強調,是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在,這才是關鍵。
再來,又如何知道上述的設計圖是正確的呢? 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確,那太耗時費工了;我強烈建議使用 物件圖 (object diagram),利用實際的案例,對應所設計的類別,很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了,讀者若有興趣,可以利用 UML 工具(如 EA)來練習看看,然後也可以把 Model 檔寄給我,多少我還能協助 Review 驗證的。
※ 延伸參考: o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇

2009年8月12日 星期三

取得重返戰場的第一塊敲門磚~ 考取OMG-Certified UML Professional Fundamental


自從2009/ 6/27、6/28參加 邱郁惠老師開的「OCUP/UML初級認證課程」,算是這10年職涯中真正踏實的進入了系統分析、設計領域,我想,這真的是我要的,短期內我可以不必再左顧PG領域的MCSD、DBA、LINQ、ASP 3.x,右盼PMP~~
2009/7/31 拿到OCUP的認證算是踏出了第一步,看到Prometric上show出的"Congratulation"時,似乎一點感覺也沒有,這應該就代表了真的是第一步,因為,在工作上我一樣無法如法如行雲流水般的將心中的系統分析、設計概念轉化為UML notation(即使已杵在那2個多小時之久了,仍不知如何下手...)。
我想,我缺的是經驗~ 缺少實際參與多樣的case study設計核心中,缺少實際自頭到尾的分析、設計過程,包含對 tool的熟悉、概念的表達...。

2009年3月25日 星期三

狂賀~中華郵政驗收了~~

就如當初在房仲那邊簽約成交我人生的第一棟房子的當下的情境一樣,心情平靜到沒有什麼喜悅的樣子,好像喝水一樣的平淡無奇,很空~~沒有什麼真實感
不過,話說回來,這真是一件很該開心的事情,至少大家這十六個月來的努力終於有了名份,上頭天一樣高的老闆也終於有笑顏了。
哈哈(乾笑兩聲)~~希望這份喜悅感能維持到這個周末,因為我知道後面還一堆狗屁倒灶的鳥事正領著幾週前就抽到的號碼牌在等我,我也彷彿聽到它正ㄎㄎ的奸笑著:等你很久了~~~~~~~

2009年3月15日 星期日

責任不能用指派的,只能讓人主動接受它

高效率的團隊往往是能夠自我管理的團隊,而且能夠充分發揮每位成員不同的專長。這樣的團隊會努力爭取挑選成員的權利,而且角色安排也很彈性,可以讓每個人選擇自己想要負責的工作。他們遵循的原則是:「責任不能用指派的;只能讓人主動接受它。」
以上節錄自「軟體工程與Microsoft Visual Studio Team System」一書。

2009年3月11日 星期三

首發~~該寫什麼ㄌㄟ~?

先想想要吃什麼午餐吧...
在中華郵政onsite的最大好處,就是這邊的美食多到不知道要怎麼選~!! 鄰永康街旁的絕佳地利,加上這邊因為有中華郵政、中華電信二大公務員集散中心~
這裡的氛圍,那種優閒的意像,著實令人嚮往。
(又離題了)~要吃什麼啊?!~