.NET Walker

從工業革命開始，工作被分成了幾種類型，為了量化生產，以供給滿足客戶大量的需求，所以生產實體產品這樣的工作，被拿到生產線上進行最佳化，目標是在最短的時間，最低的資源投入與成本耗費之下，做出一樣品質的產品。 從這個概念開始，很多管理技巧衍生出來，例如我們熟悉的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...

前一篇 我們介紹了如何在幾分鐘內建立一個Office Add-Ins，這一篇，我們回過頭來談一談，為何有Office Add-Ins這玩意兒。 首先，在我成長(也是台灣經濟快速成長)的那個年代，我幾乎可以武斷地說，所有使用個人電腦的用戶，都曾經用過Microsoft Office，甚至有許多使用者，打開電腦的目的，根本就只是使用Office軟體。當然，自從網際網路開始盛行之後，這一切變得有些不同。 微軟在很早以前，就曾經把Office定位成一個平台，而非只是一套軟體。平台，與軟體有何不同? 軟體有著特定的功能，為使用者完成特定的工作；但『平台』，則是一個基礎，一個舞台，讓用戶(或開發人員)可以基於這個平台，持續在上面擴展與發揮。微軟這個Idea，可以說成功，也可以說不成功。其中的細節我們先不談，但不論如何，Microsoft Office持續稱霸著企業應用多年，一直到今天。 然而，挑戰一直都在，曾幾何時，大家打開平板和手機的頻率，開始逐漸超過PC，才沒多久的時間，平板上的應用App，已經不僅僅是超過，而是讓PC上的軟體感到強烈的威脅。 一家企業，要能夠成功不容易，要能夠持續成功，更可以說是難上加難，難的部份不僅僅只是持續創新、不單單只靠執行和效率，更多時候，是必須忘記背後，自己把過去的成功親手掐死，然後你才能夠面對一個新的世代，走向一個嶄新的未來。 微軟，就常幹這種事情。 薩提亞·納德拉(SatyaNadella)，在2014年2月就任微軟CEO時，說道：『我們這個行業不尊重傳統，只尊重創新』。 不要覺得訝異，持續成功了三十多年的微軟，不只一次打掉重練，讓自己(的產品)破碎，然後重新開始。網際網路大勢所趨時如是、Java改變開發人員時如是，而今面對行動裝置大軍挑戰的現在，也是。 首先，微軟面對Google一系列線上Office(可以在瀏覽器中執行的類Word, Excel軟體)的挑戰，開始也跟著推出可以在瀏覽器裡面執行的Word, Excel, PowerPoint，當然，用戶可以在瀏覽器裡面編輯，並且直接把檔案儲存到Onedrive雲端空間。不僅如此，也跟用戶端的Office軟體充分整合，檔案可以下載編輯，甚至從用戶端桌面版本的Office軟體中直接編輯雲端的檔案。 接著，因應SaaS(軟體暨服務)的雲端應用程式概念，微軟推出了Office 36...