發表文章

目前顯示的是 4月, 2019的文章

世事無絕對

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

使用C#開發Linebot(30) – 使用LINE Login時取得用戶email

圖片
先前 我們介紹過了 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不同): 當我們