發表文章

中秋節前的最後一天

圖片
在中秋前失去工作,我想不會是一件讓人愉快的事情。 阿伯是我們辦公室樓下停車場的管理員,從我們承租這邊的第一天,他就在那個管理亭裡。我認識他快十年了,他永遠穿著一樣的黃色上衣,不管是颱風天還是大豔陽,總是守在那個售票亭裡,度過他的每一天。 小停車場車位很容易客滿,但我從來不用擔心,因為我可以在上班遲到時在路上打電話給他,請他偷偷幫我留一個車位。抑或是,讓我在早已經客滿的停車場稍微併排一下,如果真擋到了人,他會機警地打電話到我手機上給我…,呵呵,這顯然是一個非常人治的停車場,但是我很喜歡。 他數鈔票找零錢的時候,總會喃喃自語1,2,3,4...,認真的一張一張數過三次,這年頭這樣傳統的人已經很少見,可能是他永遠一個人在停車亭,我每次進出時,他總會試圖跟我聊天,哪怕只是一兩句閒聊或八卦。 然而,今天他告訴我,九月中之後,大樓管理人員要把停車場換成自動售票裝置(而且還順便漲價),因此,這個亭子不再需要他了。 我知道這是早晚的事,在自動化的潮流之下,會有人失去自己的工作,我一直都知道,因為我們或多或少也算是這個自動化浪潮的某種推手。 我們熱愛自動化、講求效率,我們也知道在這過程中,某些人的工作會被影響,某些人的生活或許會因此改變,只是...這些人一直離我很遠,因此我平常可以毫不在意地,轉身專注於如何為客戶提供最新的技術,如何幫助客戶降低成本,甚至是減少人力。 但在心裡我知道,總有一天,我們都會是自動化浪潮底下失去些甚麼的人。或許,失去的不是工作,也或許,失去的不只是工作... 我不知道阿伯準備好了沒有,甚至,我也不知道自己準備好了沒有。 但我想,中秋節回來之後,當我聽到自動柵欄的語音時,或許我會想念起阿伯一張一張數鈔票找零的聲音、滔滔不絕的八卦,以及親切的問候、和售票亭裡面孤獨的身影。

使用C#開發LINE Bot(32) – .net core 2.2 WebHook 範例

圖片
前面 我們談過了如何在 .ner core環境上透過 LineBotSDK發送訊息。我們今天來看如何建立一個WebHook… 我們先看執行結果: 當你跟bot說hello的時候,他會echo你hello,當你說 /show ButtonTempalte的時候,他會reply一個tempalte訊息,當你傳送貼圖的時候,它會回你一個貼圖。 我們來看WebHook的程式碼: 剛才我們說到依照用戶傳來的訊息,回覆相對的訊息的部分,是在27-78行,其中回覆文字訊息的部分是29-57行。你會看到我們在程式碼當中,透過bot物件採用ReplyToken回覆訊息。 回覆多則訊息 比較值得注意的地方是,我們回覆訊息的程式碼其實統一寫在76行,回覆的物件是responseMsgs,這是一個訊息的集合。裡面至多可以放5則訊息。而前面程式碼當中的判斷與回覆,其實只是把準備要回覆的訊息加入這個responseMsgs物件中。這樣的寫法比較理想,因為依照LINE的規格,ReplyToken只能使用一次,如此做法可以在程式碼的單一地方一次性的處理回覆,比較好管理,不容易發生replyToken使用多次的錯誤。 另外,程式碼最上面的5,6兩行,是從json檔案中取得appSetting,這是.net core新的做法,請讀者測是這個範例時,也要記得開啟appsettings.json置換當中的token與admin user ID: 程式碼的18-23行,其實就是取得LINE傳來的http body,並且透過我們的SDK Parsing成為ReceivedMessage物件,其中就包含了用戶跟我們LINE Bot對談傳來的訊息,後面25行LineEvent的操作我覺得我們的讀者應該就不陌生了。 小結 總的來說,使用.net core開發LINE Bot現在已經相對算是成熟很多了,我們的SDK目前也已經全面支援,不管是發送(push)/回覆(reply)文字或template訊息基本上都沒有甚麼問題。 而整段程式碼與過去最大的不同之處,大概只有取得config環境變數的作法稍有不同,完整的程式碼已經在 Github 上等你,請直接clone或fork下來使用即可,不用客氣。 如果你要測試,無須安裝VS 2019,使用MAC+VS Code開發也是很好的選擇,參考 前面 介紹過的做法,透過dotn...

使用C#開發LINE Bot(31) – .net core 2.2 Web範例

圖片
一路上都有不少朋友問過:『LineBotSDK怎麼還不支援 .net core呢?』 我總是回答『手邊事情太多,一直沒時間啊…』不過,老是跟人說:『你永遠有時間做你認為重要的事…』我自己卻拿沒時間當藉口,似乎有點牽強… 該怎麼說呢,總之,我覺得目前看起來, .net core 2.2 似乎是一個挺好的起跑點,所以,我們準備全面開始支援 .net core囉。 SDK 關於LineBotSDK的 .net core套件,前幾天已經跟朋友們介紹過了,我們剛更新了一個 beta3 的版本,幾乎已經可以當作正式版使用了,nuget package 可以參考底下網址: https://www.nuget.org/packages/LineBotSDK/2.0.0-beta3 這包package可以直接支援 .net framework 與 .net core,所以不管你用哪一種開發技術( 只要是 .net )你都只需要直接引用就好。所有的API都在同樣的namespace底下,如果你想把source code從WebForm轉成 .net core,也完全不用改API的用法。 razor page 範例 很久以前我就說過,上了 .net core之後,我自己大部分的專案選擇用razor pages來開發Web專案(少部分用 .net core mvc,箇中原因有機會再慢慢談,不過,.net core的WebAPI依舊是要的),所以,底下這個部分我們會直接介紹一個使用 .net core 2.2 razor pages開發以及透過 .net core WebAPI來做LINE Bot WebHook的範例。 不管你用的是MAC或是PC,不管使用VS 2019或VS Code,你都可以直接在command line底下建立一個資料夾,然後執行底下指令,clone github上的專案… git clone https://github.com/isdaviddong/LineBotSdkDotNetCoreWebExample.git 當然,別跟我說你沒安裝 Git 和 dotnet SDK 執行後你應該會看到類似底下這樣的輸出: Cloning into 'LineBotSdkDotNetCoreWebExample'... remote: Enumeratin...

使用PowerShell刪除Azure訂閱中沒有任何資源的資源群組

圖片
先前 提到,在我棄明投暗開始改用CLI之後,Windows世界裡的PowerShell我當然不可能不去碰。對PowerShell來說,我應該算是新手(資訊界非常有趣,每隔一段時間你就會自動升級為新手,偶而享受一下可以亂做一些蠢事的新手禮遇其實還挺不錯)。 而對新手來說,認識某一種工具或技術的第一件事情,當然就是拿它來弄出一個自己需要的解決方案。PowerShell對我最大的用途當然是控制Azure訂閱,而第一個讓我想幹的解決方案就是,殺光…空著的資源群組。 不知道你有沒有跟我一樣的問題,你知道,Microsoft很大方地給開發人員Azure Free trial帳號、visual studio dev essentials、上課的Azure Pass…等諸多Azure資源。這導致我有非常多的Microsoft Account(MSA)、每個Account底下有非常多的Subscription,每個Subscription底下有一堆常常移動過來移動過去的Resource Group…箇中原由就暫且不表(內行人一定知道)… 當我把Resource Group在subscription之間移來移去的過程中,總是會留下很多空的Resource Group,這很煩、很難看、很難管… 所以我閒暇之餘常常從Azure Portal進去,一個一個Resource Group點進去看看裡面有沒有Resource(這很白癡,對,我知道…)如果是空著的話我就刪除它…很久很久以前我就知道這樣很蠢,根本不是辦法…應該要寫個script去處理它… 但一來沒空二來我內心掙扎不想碰CLI,所以連帶PowerShell也不太動手…好啦,現在我洗心革面棄明投暗之後,第一件解決自己問題的PowerShell巨作,當然就是寫一個刪除empty resource group的script… 寫完之後的結果如下: 由於用到了PowerShell的az Module,如果你要拿去玩耍的話,請記得使用底下指令安Az Module: Install-Module -Name Az –AllowClobber 相關資訊可以參考: https://docs.microsoft.com/zh-tw/powershell/azure/install-az-ps?view=azps-2.4.0 如果你用Powe...

怎麼回事?我怎麼會重新愛上CLI的?

圖片
當你有一定的年紀之後,話就會愈說愈小聲。雖然我清楚地明白這個道理,但每次發生在自己身上時總是印象深刻。 常看這個blog的人應該都知道,我不太喜歡CLI( Command-Line Interface),除了因為現在的圖形化介面其實大多都做得很完善,加上我從小討厭背指令,實在記不得要完成某個動作的時候,該在鍵盤上敲下什麼…而且更主要的原因是,我經歷過那個只有CLI沒有GUI( Graphical User Interface )的年代,那個時代的工程師天天跟黑底白字(或綠字)的螢幕為伍,花上數小時在鍵盤上敲打著別人看起來完全沒有意義的文字… 我也不例外,副作用之一當然是練就了超快的打字速度…但其實頗為辛苦。所以當GUI出現的時候,我和很多那個年代的工程師一樣,是大聲頌揚大力鼓吹的,並且對CLI棄之如敝屣。 一晃眼30多年過去了… 最近這幾年,CLI居然又成為主流,我在心理上其實很難立刻接受。(你會發現人的既定印象與觀念有時真的很死板,一旦形成後,無法改變到難以想像的地步)我始終認為,只要在有設計良好的GUI的前提下,我根本沒什麼理由需要跟以前一樣一天到晚用力敲打鍵盤! 直到… 最近因為上課的關係,需要實現『金絲雀佈署』,這導致我常常需要一口氣建立兩三個Web Site Slot,並且在不同的slot分別各自佈署網站(這還只是暖場)。然後,為了實現金絲雀,我必須要先在第一個網站佈署新版,然後透過Web App的traffic management改變流量,把10%流量導入第一個站台,依此類推,直到最後一個站台佈署完新版… 第一次,我用Azure Web UI用到覺得很X。 當我發現,過程中我少做(或做錯)了一個步驟,導致設定配置有錯誤的時候,為了讓整個Lab環境乾淨且順暢一點,我發現我得要重來 >_<。 佈署到第三輪之後,我開始覺得這樣在網頁上用滑鼠點來點去實在不行。 就在這一刻,我竟然毫不猶豫的打開了powershell: 其實過去就安裝過了azure cli,所以我隨手把建立網站的指令打了進去,不夠確定的話還可以請AI神燈阿拉丁幫忙查詢(在上面,有看到嗎,哈)…後來發現,我與其這樣一行一行打,不如用VS Code編輯。接著開了VS Code,想到印象中有一個azure cli套件,可以有intellisense的功能,還可以在VS Code裡面直接r...

Azure DevOps(VSTS)的CLI命令列工具

圖片
你大概知道以前Azure DevOps叫做VSTS,其實打從VSTS時代,它就有一個很好用的CLI工具,就叫做VSTS CLI。 你可以從底下位置下載: https://aka.ms/vsts-cli-windows-installer 頁面位於: https://docs.microsoft.com/en-us/cli/vsts/install?view=vsts-cli-latest 它可以幹啥呢? 基本上可以透過命令列的方式做所有事情,當然你必須先設定好環境和權限。下載後請先安裝: 安裝完成後,你就可以在命令列使用這個工具了,先來測試一下: 確定可以使用之後,我們先做一些基本設定,使用vsts configure指令之後,基本上都用預設值即可: 完成之後,我們就要登入了,可以透過底下指令,加上你的Personal Access Token: Personal Access Token可以在Azure DevOps站台上申請: 來連結到一個azure devops專案試試看: 完成後,我們來測試一個好玩的指令: 輸入之後,你會發現所有人員登入azure DevOps網站之後,都會出現底下提示: 哈哈,我們把Azure DevOps變成Developers的公告系統了。 當然CLI的功能不只如此,舉凡建立專案、自動建置、套件管理、工作項維護…幾乎所有重要工作都可以透過CLI命令列來做,它是一個非常強大好用的管理工具。 不妨找時間玩玩看囉。 --- btw, vsts cli近期會改為 Azure CLI 的一部分,透過 Azure DevOps extension 來整合,後續再為大家介紹這個部分。

你準備往哪裡走…?

圖片
還記得我在研討會常講的那個故事嗎? 某次我老闆急著趕去會場,由於正在準備接下來會議的主講內容,手上拿著稿件低頭攔車,因為快要遲到,他跳上計程車後情急地說:『快…開快點。』卻忘了計程車駕駛壓根不是平時幫他駕車的司機,根本不可能知道他要去哪。 只見計程車司機二話不說猛踩油門車子狂飆了三個路口之後,我老闆才想到似乎有點不對,問計程車司機說:『我剛有跟你說要去哪嗎?』 司機驕傲地回答:『沒有,不過,我確實有開的很快,對吧?』 最近開始認真讀那本暢銷的OKR(先前是有看過一些介紹文章,但只能大致掌握基本概念),不過讀著讀著又開始覺得,近代幾乎每一本實用的管理書籍,都曾在書中以不同的姿態告訴你 目標 有多重要,而『認真地』訂出目標幾乎是一切管理的根本。 不管是 柯維 的 與成功有約 系列、 高德拉特 的 目標 系列、最近我很喜歡的『執行力的修練』、管理大師 杜拉克 的演講或著作、坊間流行的KPI和OKR...每一種方法論其實都在跟我們說同一件事情... 『若你沒有認真的訂出目標,就什麼都別談。』 這個道理其實大家都懂,但環顧身邊,有認真訂出目標的人似乎還真的不多。 的確,我們每個人或多或少都有(過)目標,但我們面對自己的目標到底有多認真呢? 我依稀還記得20多年前我的管理學老師在課堂上說:『你絕對可以實現任何 (他強調任何) 你想實現的目標,只要你「現在」把它寫在紙上。』他說『關鍵不在於你訂的目標有多麼大,而是你到底有多認真,你到底有渴望實現這個目標,願意為它附上多大代價...』 當然,那天全班沒人理會他說的話,當下我甚至有點懷疑他自己到底相不相信自己現在在說什麼? 20多年後,我唯一後悔的是當時寫下的目標太小。 當年他說,有一個非常簡單的指標,能夠衡量出你對這個目標有多認真。 不,不是你有多慎重的把它記錄在高價的筆記本上,也不是你每天把它拿出來膜拜的次數有多少。而是…你身邊和你最親近的人當中(朋友、家人、同學同事...),有多少人知道你的目標? 有多少人能在不需要提示的狀況下,就能清楚的說出你訂的目標,這些人愈多,你的目標實現的可能性愈大...,如果你身邊還沒有這樣的人,從今天開始,把你的目標寫在紙上,貼在你的書桌前、房門口、座位上…讓每一個你身邊的人,都知道你的目標是什麼… 不知道為什麼,他當年說的每一句話,我至今還記得相當清楚... 20...

Improvise

圖片
今天在改一個以前自己寫的系統。 愈改愈覺得,當初怎麼會這樣設計的? 很多寫法實在看不下去,只好重構一番,把過去的一些設計和架構做些調整和改善。我猜,只要你是職業(不需要是專業)的開發者,肯定也曾有過這樣的經驗。 我們常常覺得過去的東西似乎還有可以改善的空間,所以,系統就這樣在修修補補之中度日。 曾經我覺得這樣子不行,所以花了一些時間認真學習各種pattern、架構設計、框架開發...等知識技能,想說從此之後,應該能高枕無憂,在開發時做出比較能夠長治久安的設計。 結果呢? 跟你猜的一樣,並沒有。系統還是在修修補補中度日。這到底是為什麼? 幾年之後我知道,原因很簡單,因為環境在變,技術在變,需求在變,我們活在一個多變的真實世界,然而我們能控制、能掌握的變數實在太少,少到所有的預先規劃和設計最後看起來都變得可笑。 所以,敏捷(Agile)不相信計畫(Plan),甚至誇張一點說,敏捷不相信有完美的預先設計(Design)。 但注意,這不是完全不要設計,而是,不管當時看起來怎麼完美的設計,你都要有這個心理認知--『 日後它一定會變得不完美 』。不管你做了什麼樣精細的計畫(Plan)你都要知道,這計畫未來一定會走歪,只要你是活在一個充滿變數與未知的真實世界中。 你不相信? 或許你會問,那為何過去的年代,計畫似乎是有用的,甚至有人手上可以有好幾套劇本,事情的走向總是被掌握在足智多謀、細心計畫的智者手中? 那是因為過去的時代沒有現今的科技與技術,資訊的傳遞也不像現在這麼迅速,當時的世界給了人們一個假象,讓人誤以為自己可以掌握些什麼,能夠控制些什麼,能夠讓事情的走向依照計畫,或是運籌在股掌之間。 也確實,當你手上的資源越多、運算能力越強大,面對的問題越簡單、變數越少、時間越短,那預測和掌握未來的可能性不是不存在。 反之,當你手上的資源越少、變數越多、你就會發現對未來的掌握度趨近於零,事事依照計畫走的可能性根本不存在。 所以我們乾脆不要計劃了? 開發時也不用做任何架構設計? 對,也不對。 對的是這個想法,預先計畫和預先設計並不可靠,這意味著你不能完全倚賴它。 不對的是這個行為,你不能完全不做任何計劃或設計,你只是不該再像是以前那樣鉅細靡遺地去設計,並要求所有人照著劇本走,期待規劃好了就不會再改變。 會不會很矛盾? 對我來說完全不會,因為這就是人生。 ...

世事無絕對

#世事無絕對 #分久必合 #合久必分 #潮流 如果你是從Basic/C/Pascal那個年代開始學程式設計,印象中老師會暗示學生說 COBOL 是一種相對不受歡迎(或落後)的程式設計語言,那時候大家(主流市場)看起來都很感冒 COBOL 那種縮排式、英文句型式的語法,當時從沒聽過有人覺得 COBOL 的 "高可讀性" 具有任何的可取之處... 我也只是因為好奇寫過一兩次,之後沒多久,它就消失在整個 C like languages 的風潮之下... 正當我以為未來的人生再也碰不到類似的程式撰寫風格時,python出現了...說實話,我真的很難接受不用 { ... } 作為區塊的程式設計語言...我覺得python的走紅估計應該是一個意外... 但,沒多久,我又碰到了YAML...,然後我開始聽到許多人讚揚python和YAML這種 "高可讀性" 的程式設計語法! 這使得我有點混亂了... 這讓我開始懷疑當年厭惡 COBOL 到底是不是一個理智的決定? 還是只是人云亦云的結果? YAML有高可讀性? 怎麼我覺得JSON比較好讀呢? 我猜,這是因為十幾年 {...} 的洗禮下來,老人的腦袋結構已經有些轉變了的原因... 但對於初踏入這個世界的初學者來說,python/YAML或許確實真的比較好讀...(可現在的我真的已經無法體會了 >_< )... 環境氛圍改變了我們的喜好,而喜好和習慣又改變了我們的價值觀。 隨著年紀的遞增,我發現確實有些事情是我沒法理解的。 而無法理解的事情,又怎麼能去評論對錯呢?

產品的價值

圖片
做軟體開發很多年之後,常碰到有人問我,軟體公司是怎麼估算一套軟體的價格的? 用開發的人天數來算嗎? No, No, No…『人天數』是一個非常標準的 錯誤答案 。 如果你是軟體開發商,軟體開發的『人天數』可能是你的成本,但絕對不會是報價/售價。 那報價/售價怎麼定呢? 讓我先問一個問題... 對於買方來說,什麼叫做『買貴了一套軟體』? 或者反過來問,什麼叫做『買了一套划算的軟體』? 不好回答? 想一想底下的例子... 如果軟體開發商花5個人月為買方(你的公司)客製化開發了一套系統,然後賣你500萬,對你來說,這貴不貴? 其實我們不知道。因為貴不貴是相對於這套軟體能為你帶來多少價值而定的? (而非開發商花了多少時間) 如果你花了500萬,系統上線後,能每個月為你帶來50萬的效益,那我覺得這500萬算很值了。但...如果系統上線了,一年後都沒法為你帶回幾十萬的效益,甚至還讓你虧錢(請相信我,類似上線後還虧/花大錢的案例你在資訊界隨便問都一票),那不管這套軟體廠商是花十幾上百個月,對你來說這套系統都是買貴了,一點都不划算,應該說,這軟體一點意義都沒有。 如果你同意這個思維,大概就能理解,軟體開發的報價不該是用人天來算,況且,一個軟體開發高手跟一個會寫程式的菜鳥初學者,兩個人『一天』的產出差異恐怕可以達十倍以上,但你有看過人天報價level差異化到十倍的水準嗎?應該從來沒有吧。 那有沒有覺得很奇怪,如果軟體不該用人天來計價,那為何打從你第一天進到這個產業,一直到今天,都還是會常常聽到人月或人天這個計價單位呢?   有一種可能是,我們其實不怎麼知道(不會、不敢、或不願)去評估一套軟體系統的『價值(Value)』。 很難理解? 其實這就如同大部分的公司其實很難評估一個員工的產值一樣。 若當公司不知道該怎麼(或不願意)去衡量員工的產值時,往往就只好拿 其他看起來很公平客觀的數字 (例如出席狀況和上班工時)來決定員工的價值了。而這正是一種非常古老落後且糟糕的方式。 久而久之,當員工養成習慣用『在辦公室出現的時數』,甚至是加班時數、配合度…來彰顯自己價值時,其實也多半意味著,手上根本沒有一張漂亮的成績單,漂亮到可以拿出來凸顯自己的存在對公司的意義。常常有人說,準時上下班是最基本的,這話一體兩面,準時出現在辦公室確實真的就只是『最基本的』。 時代變化的很...