.NET Walker

是這樣的，我一直用Blogger的blog，本來也都是徒手張貼blog，後來有人跟我說，Windows Live Writer(WLW)很好用，所以我就從善如流的用了，發現還不錯用，但好日子過了沒多久，前幾天，它突然無法登入Blogger了! 原因是，Google把登入機制改成 oAuth 2.0，但為何要改呢? 因為它們早就想改了( 前情提要 )。 而等到現在，是因為MS終於把WLW給open source了( 參考 )。 所以，Live Writer以後就由廣大的社群&善心人士共同維護了，名稱從此變為OLW(Open Live Writer)從11號等到17號，終於，善心人士釋出了新版的OLW(可以從 這邊 下載)，所以現在你又可以用OLW登入並撰寫Blogger的文章了(如果先前有安裝，要記得移除)。 這一篇，就是用OLW寫的，對於廣大社群與善心人士的孜孜不倦，無以為報，謹以此文紀念。

我是沒甚麼看影劇節目的人，但今天在網上看到一篇文章，描述今年角逐金馬獎的宋芸樺，被主辦單位臨時邀請代替Hebe演唱<小幸運>，只猶豫了兩天，就決定上陣。上網看了一下影片，發現唱的還真不錯，但重點是，一位演員有這個勇氣和實力，很讓人敬佩。 或許，她平時就有練習，甚至，其實她打算同時朝歌手發展，但在這一個關鍵場合的良好呈現，肯定為自己未來的路擴展了更多的機會。 讓我不免回憶起，過去在擔任各種角色時，自己真的碰到很多需要硬著頭皮上的場合，大多時候表現得還可以，當然也有因為硬著頭皮上結果不是很理想的時候。但，我幾乎沒有放棄過任何一次關鍵場合上場的機會。在當開發人員的時候，常被抓去兼任PM、在當講師的時候，常常被找去做顧問服務、許多次臨時被找去代課…回想過去，其實很多工作，都是在沒有預先通知的狀況下被臨時賦予的。 這時，就是考驗平時的準備與臨場功力的時候了，在一個有充分時間準備的場合展現，多半看不出你的實力，但臨時上場的考驗，往往立刻淬鍊出你的真實程度。 過去，在職場上，很多技術人員常常跟我說，想要往顧問或是PM的角色發展，但苦無機會，其實我覺得，機會，多半都是被我們自己放棄掉的。 下一次，碰到關鍵時刻，被臨時叫上台簡報、被突然間賦予自己不擅長的任務、被緊急抓去救火，千萬別因為自己不擅長或是膽怯而說NO了。用力把握每一次展現自己的時刻，把這個場合當作一個機會，日後更多的機會自然就會主動找上你，不論在你準備好還是沒準備好的時候。 至於『準備』，就看你平時是怎麼過每一天的了。我常說：『你的時間在哪裡，你的成就就在哪裡。』 ref: http://www.setn.com/News.aspx?NewsID=107676 ref: https://www.facebook.com/sungyuhua/photos/a.441771815951334.1073741828.440923442702838/787757738019405/?type=3&theater 宋芸樺現場演唱(從1:45開始): 平時的準備就很重要:

2015/11月底，微軟在Connect();大會，正式公布了大幅度改版的線上TFS，也就是變了新名字的VSTS(Visual Studio Team Services，從前叫VSO)。 VSTS可視為線上版的TFS，讓開發人員可以對軟體的生命週期做非常良好的管理，是一套ALM軟體服務。翻成白話一點，就是軟體專案的統籌管理軟體。 更新後的VSTS，除了原本的版控、自動化建置、測試，以及工作項目管理之外，加上了眾人期待已久的數位儀表板功能： 這個討喜的功能，讓團隊以及PM/PO可以一目了然的看到整個專案的整體狀況，當然，這個儀表板是可以客製化的，有各式各樣的組件，可供專案管理人員選擇應用，您也可以為專案建立多組儀表板，分門別類的以視覺化方式來呈現所有資訊。 我們接著就來看，如何客製化這個數位儀表板。 (等等，你竟然還沒申請免費的VSTS專案管理服務? 請參考 這裡 。) 如果你有管理員權限，現在，進入VSTS專案之後，你會看到overview頁面上，右下角有一個『+』符號： 按下上圖右下角的按鈕，會出現一堆的Widget供你選擇，你可以隨意用滑鼠選擇一個或多個，佈置在預設的數位儀表板上： 類似像上圖這樣，可以點選幾個widget(被點選的會打勾)，按下新增(add)之後，即可加入: 這很簡單，但重點是，這些圖表有何用途? 如果熟悉TFS/VSTS使用或和我們一樣採用Scrum開發框架的朋友們，應該很熟悉了，你可以在畫面上看到底下這些: 這些都是從library直接抓取出來的Widget，當然，你也可自行建立不同的查詢(Query)，以呈現想要的結果。 例如，我們可以在work底下的Queries中，建立一個Query: 我們查詢專案中所有的Backlogs，儲存完成後，移入Shared Queries： 接著，建立一個新的Chart: 有各種圖表可以選擇，我們選擇Pie圖，並設定Group by “state” 欄位: 我們設計好圖表之後，可以透過圖表右上角的選單，把圖表釘選到數位儀表板上: 我們看看: 成功的在數位儀表板上，把Backlogs的狀態顯示出來囉。如此一來，一目了然的呈現出整個專案的狀況，老闆、客戶和PM還能說專案不夠透明嗎? 不僅如此，還有個好玩的功能，Query Tile讓你可以針對某一個數字設定紅綠燈警示看板，你可以點選Q...

從工業革命開始，工作被分成了幾種類型，為了量化生產，以供給滿足客戶大量的需求，所以生產實體產品這樣的工作，被拿到生產線上進行最佳化，目標是在最短的時間，最低的資源投入與成本耗費之下，做出一樣品質的產品。 從這個概念開始，很多管理技巧衍生出來，例如我們熟悉的SOP，我們過去常用的甘特圖，計算績效的KPI…凡此種種，都是從這種基礎概念產生的理論。 但，有一種類型的工作很難被SOP規範、很難用KPI管理、也幾乎無法被甘特圖預測，那就是創意工作，諸如，藝術品、歌曲、文章…的生產。而我得說，程式設計，其實也是其中之一，但往往被忽略的很徹底。 為何這類的創意工作不能被傳統管理工具有效管理，本質原因很簡單，因為能透過標準作業程序管理的生產行為，大多是追求著產出"完全一樣"的"實體成果"，小到一顆螺絲釘，大到一台BMW汽車、在生產規劃的那一刻，其目標就是希望生產出一模一樣的東西，沒有人希望這類產品的產線在生產的時候，出來的每一個成品都有自己獨一無二的特色，如果是，哪怕只是多了一兩克重量，都會讓人難以接受。 但創意工作不是，沒有一首曲子100%完全一樣，如果有，就變成了抄襲，藝術品、創意工作所產出的成果，之所以有其價值，就是在那95%類似的元素之外，那5%的一點差異。 藝術品和創意工作，容或製作生產的流程相同、投入的資源類似，但一旦落入模仿或臨摹，其價值就一落千丈，和這市場上其他的商品不同，其差異就在於對價值的認定。 很不幸的是，電腦軟體也是如此。天下沒有兩套完全一樣的軟體，因為不需要，如果完全一樣，你copy一分就可以了。電腦"可程式化"的目的就在於面對變化，面對差異，然而麻煩的地方就在那5%的差異。這5%的差異，讓程式設計從工業工作變成了創意工作，而”人”在其中就變成了一個很大的變數。(如果完全一樣，就不會有問題，也不需要額外寫程式，就是因為不完全一樣，才需要再次撰寫程式碼) 過去20年，軟體工業一直企圖把程式設計（軟體開發）變成一個標準化的動作，我們夢想著用OOP，就可以讓一切變的組件化、好讓程式的組成變得容易。我們從工業管理生產線上學來SOP、KPI、Gantt Chart，想要用一樣的方式管理程式設計師的產出，用同樣的方式提高產量，但努力了20年，卻發現離理想越來越遠(早期軟體生命周期很長，半年才一...

第三天的Office Add-Ins介紹也順利的完成囉，我後續會把影片、投影片和相關的範例逐步整理到blog上，謝謝當天留到最後的學員們，以及每一位參與學員的支持。 先前已經有整理好的幾篇blog，連結如下: http://studyhost.blogspot.tw/search/label/Office%20Add-Ins 可提供各位先參考。 updated: 投影片位於 這裡 ，現場影片位於 這裡

很高興今天在會場有機會看到許多老朋友，並且和大家分享了我們在CI/CD以及Scrum上的一些心得，場次[實現 End to End 的雲端敏捷開發流程]的投影片可由底下連結 下載 。 希望對大家有幫助。 20150930: [TechDays現場錄影] 今年，現場video好快就上架了，沒有來現場的朋友們，也可以聽一下我們在CI/CD這個主題上的分享囉，聽的時候千萬別怪我囉嗦，前面講了一堆有的沒的，如果你長期關注我們的FB/blog，相信你可以理解為何我們會有感而發…不論如何，謝謝大家的包容與支持。有一點小遺憾，現場的錄音把講員的聲音錄的很清楚，但卻錄不到現場學員的笑聲，現場其實充滿了歡笑和樂趣，而會後和學員們的討論，也讓我自己收穫很多，下次來現場吧，希望有機會碰到大家。 https://channel9.msdn.com/events/TechDays/TechDays-Taiwan-2015/DEV302

前幾天，看了一篇 文章 ，看完之後我立即在FB上分享，原因不僅僅是因為文章中描述的雖然以設計界為主體，但根本120%符合台灣軟體專案外包的現況。我本來想節錄其中讓我很感慨的幾句話，但我回頭再看一次 文章 ，發現我不用節錄什麼，我推薦讀者整篇重頭到尾讀一遍就對了。 接著，我想說說我的感受。 最近十年，我剛好身兼文中所說的幾種工作，資訊軟體開發的教育訓練、雜誌專欄文章撰寫、書籍出版、同時也在業界接案、甚至擔任顧問，台灣軟體專案發包的低價、浮濫…等問題，跟文中說的完全一樣，我們非常明白這件事情。(因此看完之後，我沉思良久) 但如果說，我們在接案時跟其他人一樣，必須被迫用較低的價格來接案，這只說明了一件事情，就是『客戶覺得我們不夠專業』，我們不夠優秀到讓客戶願意用比別人更高的價格，來聘請我們為他服務。簡單的說，就是如此而已。 你說市場行情，沒錯，市場行情是一回事，但對於追求專業的我們來說，我們總是期許(要求)自己所做的每一項工作，都有著比他人高的品質和效率，這意味著，我們期許自己比其他同業要來的專業，果真如此，那在價格上應該要比一般"行情"要來的高一些才對。 如果客戶不願意用比市場行情高的價格，來聘請我們，那顯然該檢討的不是客戶，而是我們自己。我們是否曾在客戶面前彰顯了自己的能力? 我們是否讓客戶感受到十足的值得信任? 客戶和我們溝通的過程中，是否就能夠體會到所謂的專業? 是否與我們對談本身，對客戶來說就已經是一種收穫? 如果不是，那表示我們還必須努力。 當然，容或有一些客戶 對專業沒興趣 ，只希望用最低的價格拿到堪用的成品，但這本來也就不是我們想要爭取的對象。 最近十年，軟體或網站開發比起過去容易非常多，隨便一個學生或是上過職訓的SOHO，都能夠拿起開發工具寫code(沒什麼好怨的，我們自己都帶過這樣的教育訓練課程，也都在台上跟學員說，你看，你看，就這樣，很簡單吧…)。 但，如果只是把程式碼寫出來，讓網站可以動，那顯然無法彰顯你的專業。 在這個業界待了五年、十年、甚至二十年，和剛畢業的學生有何差別? 當破壞行情的份子在業界用極低的價格承接專案的同時，我們能否清楚地跟客戶說明，為何我們值得比較高的報價? 軟體開發或網站設計為何不僅僅只是寫代碼? 一個優秀的系統還包含了哪些要素? (穩定性? 延展性? 安全性?) 好的專案管理該如何凸...

前一陣子到某家公司進行教育訓練，談的是專案管理與ALM。席間，有位學員問到：『Scrum鼓勵溝通，但要怎樣才能夠讓成員凝聚出團隊氣氛，讓大家真的進行溝通，並且引導同仁往持續改善的方向前進呢?』 我很能理解這個問題，因為卓越的工程師普遍喜歡自己一個人埋頭寫code，對解決技術問題都有自己的一套想法，但要習慣性地跟其他人一起合作，有時似乎還挺困難。這位提問者是公司的主管，他嘗試過讓這些團隊成員到外面上溝通的課程、訓練團隊成員溝通的技巧，甚至把溝通這件事情當作績效指標，結果…不出你的預料，完全沒效。團隊成員好像更不喜歡講話了。 回答這個學員的問題前，我先跟這位學員說了一個我最近在一本書上(關鍵18分鐘)看到的一段故事。 書籍的作者有次造訪一座部落平原，搭乘著老舊的火車，乘車過程中，他看到有一頭雄偉的獅子 · 蹲伏在山丘頂的岩石上，看得清楚極了。 作者問列車上的管理員：『這麼巧，竟然能夠遇到獅子出來 · 這樣算是相當幸運的吧?』 『那頭獅子一向都在那裡，牠總是坐在岩石上。』對方這麼回答。 『真的? 你們用什麼辦法 · 讓牠一直待在那裡???』作者問。 管理員笑而不答。 學員們疑惑的同時，我接著說了書上的另一個故事： 『曾經有一位主管向HR顧問抱怨他們公司的接待人員不夠熱情，看到有人走進服務櫃台卻沒有表現出友善的態度。顧問實際上瞭解了狀況之後，發現根本不需要讓接待人員接受任何額外的教育訓練，也不需要複雜的績效制度，只需要把接待檯前面像是郵局櫃台一樣的那個售票窗口的玻璃移除，同時降低櫃檯的高度，服務人員的態度立即有了明顯的改善。』 真的有用? 是的，因為人們非常容易受到環境的引導和暗示。 接著，我把我們某個專案團隊的照片開給他看，並且問：有沒有發現，和一般的辦公室比起來，位子和位子之間少了什麼? 沒錯，少了隔板。 如果你一邊鼓勵團隊溝通，一邊卻讓每一個團隊成員都坐在像是城堡一樣高度的Office Partition座位中，那溝通是不容易發生的。反之，把隔板拿掉，讓team member面對面，眼神可以隨時看到對方，如此一來，團隊成員之間的交流會自然而然的形成，不需要額外的教育訓練與獎勵制度，不需要導入績效管理。事實上，最有效的方式，就只是一個環境的改變而已。 同樣的，在實施敏捷開發的許許多多做法當中，最不需要的就是導入KPI之類的績效制...

談完setSelectedDataAsync之後，我們來看看getSelectedDataAsync這個API，有填入當然就有取得，getSelectedDataAsync的功能非常簡單，就是取得用戶選取範圍的資料，我們看底下的程式碼： function getTextData() {     //調用API填入文字     Office.context.document.getSelectedDataAsync(Office.CoercionType.Text,     //call back     function (asyncResult) {         var error = asyncResult.error;         //如果失敗         if (asyncResult.status == "failed") {             //顯示失敗訊息             app.showNotification(error.name + ": " + error.message);         }         else {             //顯示成功訊息             app.showNotificat...

先前我們談到，我們在開發Office Add-Ins(特別是Task Pane與Content Add-in)時，大部分的API都從『Office.context.document…』而來，而這個從Office開頭的API，來源就是我們在html頁面上所引入的Office.js，請注意，Office.js並非一個檔案，而是一整組 office.js ，這是一大組 javaScript files的集合，如果你透過Visual Studio開發的話，可以看到專案目錄下有許多檔案: 其中的細節我們後面有機會再討論，先來看看我們常用的兩個API。getSelectedDataAsync與setSelectedDataAsync這兩個方法。 設定(填入)選取區域 我們先看setSelectedDataAsync這個方法的定義： 範例： Office.context.document.setSelectedDataAsync(data [, options], callback); 其中data參數的可用內容如下： 參數 內容 備註 data string (Office.CoercionType.Text) Excel、 Excel Online、 PowerPoint、 PowerPoint Online、 Word，以及只Word Online   array的陣列 (Office.CoercionType.Matrix) Excel、 Word，以及只Word Online   TableData (Office.CoercionType.Table) Access、 Excel、 Word、 僅限Word Online   html Word，並只Word Online   Office Open XML 僅限Word 基本上setSelectedDataAsync的功能就是將特定的文字或物件，填入當前用戶在文件當中的選取區域。 例如，底下這段很簡單的程式碼，可將特定文字填入文件當中： // 從目前文件選取範圍讀取資料，並且顯示通知 function FillText() {     //調用API填入...

不管你是透過NAPA 或是Visual Studio來開發Office Add-Ins，建構出的Task Pane Add-Ins專案，在App Body的部分，結構都是底下這樣： 我們前面曾經提過，進入點Home.html是從manifest檔案那邊設定的，你當然可以改變這個設定。 整個App都是透過HTML與JavaScript撰寫，我們先來看Home.html部分。 Home.html 我們開啟Home.html，你會發現頁面結構如下： 你會發現主畫面<Body>標記裡面被兩個<div>區分，分別是content-header，以及content-main。(上圖) content-header的部分是標題，呈現出來向是底下的『歡迎』部分： 而content-main則是上圖除了藍色的歡迎區塊以外的其他內容。一般來說我們把App主程式放在content-main當中。 前面說過，這個Home.html是app的進入點，是在Manifest當中設置的，當然，你也可以在專案中新增一個或多個HTML Page，我會建議你直接在Visual Studio當中複製Home.html即可： 當然，複製完後你要修改一下檔名(例如Page2.html)。接著，我們來修改一下Home.html的內容： 我們加上了一行程式碼： <button onclick="javascript: location.href = 'Page2.html';">跳到Page2</button> 你會發現，主頁面上多了一個Button，並且，點選之後會跳到另一個Page2.html： 這沒什麼，就是網頁的基本行為，對於常寫JavaScript的開發人員來，就是家常便飯一般。 不過，從這邊你就看的出來，我們的Task Pane Add-Ins，基本上就是一個Html page，而上面可以運行JavaScript，必要時我們可以撰寫多個html，透過JavaScript在多個頁面中切換。 Home.js 緊接著，我們來看看Home.js這個檔案，從Home.html的頁面上我們發現，這是該Page所引入的唯一一個直屬javascript file(另外兩個是office.js與App.js)。 該檔案內...

要討論Office Add-Ins的架構之前，我們得先知道它目前有哪些類型，如不論你用NAPA或是VS，都可以透過開發工具建立底下三種Office Add-Ins其中之一，分別是： 1. Task Pane Apps 2. Content Apps 3. Mail Apps 分別說明如後。 Task Pane Apps 這種類型的App可在Word, Excel, Porint, Project…等環境中使用，可以說是最廣泛的應用程式類型，主要UI出現在畫面的右方，我們剛才開發的第一個App就是屬於這種類型： Task Pane Add-Ins可以跟Office文件互動，讀取、填入文件當中的文字或表格，也可以更進一步的抓取文件當中用戶選取的區域，甚至進行該區域的綁定，一但選取區域有所變動時，我們的App可以得知該事件，並透過JavaScript配合Restful API進行進一步的一些後續動作。 Content App Content App最大的差異，是UI主體是崁入在Office文件當中的： 當然，Content App也是透過JavaScript撰寫，由於這類型的App主要是崁入在Office文件當中，因此最常用的功能與形式，是擴充Office文件原本無法實現的功能。(利如上圖中的地圖，是依照Excel中的數字即時繪製出來的) Content App跟Task Pane App一樣，可以讀寫Office文件中的內容，我們可以透過Content App，將這些資訊當作參數，調用Content App中的Restful API，計算出我們要的結果，並呈現在Office文件中。(另一個典型的例子，就是股市或匯率即時查詢) Mail App 第三種是Mail App，是配合Outlook的Add-Ins，這種類型的App和前兩種截然不同，它不只有一個主UI，而是兩個，分別叫做Compose Form和Read Form。 底下是Read Form的介面： 顧名思義，Compose Form是出現在用戶撰寫Email和Appointment的時候使用，而Read Form則是在用戶讀取Email和Appointment的時候使用。 沒錯，Mail App不僅可以與email配合，也可以與Appointment配合，這讓Mail Ap...