.NET Walker

#世事無絕對 #分久必合 #合久必分 #潮流 如果你是從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)』。 很難理解? 其實這就如同大部分的公司其實很難評估一個員工的產值一樣。 若當公司不知道該怎麼(或不願意)去衡量員工的產值時，往往就只好拿 其他看起來很公平客觀的數字 (例如出席狀況和上班工時)來決定員工的價值了。而這正是一種非常古老落後且糟糕的方式。 久而久之，當員工養成習慣用『在辦公室出現的時數』，甚至是加班時數、配合度…來彰顯自己價值時，其實也多半意味著，手上根本沒有一張漂亮的成績單，漂亮到可以拿出來凸顯自己的存在對公司的意義。常常有人說，準時上下班是最基本的，這話一體兩面，準時出現在辦公室確實真的就只是『最基本的』。 時代變化的很快，在過

先前 我們介紹過了 LINE Login這個機制，它可以讓我們的網站像是使用Google帳號做SSO(Single Sign On)一樣，達成單一登入的功能。 一旦完成整合之後，未來你的網站上的用戶，將可以用LINE帳號登入，而不需要記憶太多組帳號密碼。這和透過Google/Microsoft/FB做SSO效果相同，但，整合LINE Login有一個額外的好處，就是你有機會取得用戶的User Id，直接透過Line Bot發(Push)訊息給該用戶。這點是Google/Microsoft SSO無法實現的... 底下這個範例大致展示了如何實現LINE Login的基本功能： https://github.com/isdaviddong/Line_Login_Example 其中有一個常被開發人員問到的問題。 使用LINE Login的時候，可以透過取得的Access Token得知用戶的User ID(這很好用，只要綁定同一個Prodiver底下的LINE Bot，我們就有機會可以直接Push訊息給用戶)和Display Name、頭像…等資訊。 那可以知道用戶的email嗎? 答案是可以的，我們可以取得用戶的email。 不過有一些前提，也不難，只要你在建立LINE Login Channel的時候，Apply一下Email就可以了： 請在上面這個LINE Login後台Channel的選項中，選擇Submit，接著在跳出來的畫面中： 勾選最上方的兩個同意事項(當然，請先看過內容)，然後上傳一個截圖(證明你的Web應用程式或網站有跟用戶說明你會索取用戶的email並且徵求用戶的同意使用)，完成後，會發現它就變成applied： 接著，調整一下你的登入轉址程式碼，在scope部分加上openid與email： 如此一來，你會發現用戶登入時，LINE Login會跟用戶索取email： 當用戶同意，並且成功登入，導回callback URL之後，你可以透過底下這段程式碼，來取得用戶的email： 搞定~看起來超簡單。 如何完成的? 說明一下背景觀念。 這是因為當我們配置了scope=openid%20profile%20email之後，LINE Login回傳的Token JSON之中，包含了id_token這個資訊(請注意，與access_token不同)： 當我們