Quantcast
Channel: Blog E
Viewing all 540 articles
Browse latest View live

[學習心得][Golang] Go 1.16 新功能的「版本撤回(下架)」(Go Modules retraction)

$
0
0

前言:

Go Module 在 1.11 的版本正式導入了 Golang Modules讓許多套件可以使用 Go Module 來管理相依 (Dependency) 的套件。並且在 Go 1.16 版本也預設開啟了 Go Modules 的選項。但是在開發套件 (Package) 的時候可能會發生以下的問題:

  • 忽然發現某個的套件有重大的問題,希望其他人不要使用到這個套件。
  • 不小心進版號進太多了,而且有一些人也使用到這些版本。 (e.g 本來要跑 v0.4.0 ,結果不小心寫成 v1.0.0 )

以上兩個問題,如果在套件還沒有散佈出去的話,其實都是沒有問題的。但是如果套件也散布出去的話,就需要透過套件的撤回(Retract) ,來讓使用套件的開發者能了解相關的問題,也讓之後使用的人不會再用到這個版號。

本篇文章將會介紹 Go 1.16 裡面一個比較沒有被重點宣傳的功能(大部分人注意的是 Apple M1 支援),並且透過官方給的線上範例也給版本撤回的實作。

TL;DR

本篇文將要介紹:

什麼是 Retraction ?

顧名思義就是版本的撤回,也就是將「有問題」的版本將以撤回。

為何需要 Retraction ?

通常有兩類的問題:

  • 「已經發佈」的版本中,有某個版本發現致命的錯誤需要撤回。
    • 其中「已經發佈」代表已經公開發佈在 github (或其他 repository) ,並且有人使用。
  • 不小心將版本號碼打錯了,比如說 0.4.0 的版本,後來不小心打成 1.0.0 但是又被人拿去使用。

以前要如合作撤回版本的方式

由於以往並沒有提供 Go Module Retraction ,所以發生以上情形,只能在 README 上面註解。 並沒有方式在 go get 同時獲得足夠的資訊。

如何使用 Go modules Retraction

這裡透過線上 Go Dev Playground,直接一步步講解主要的問題解決方式。 詳細的程式碼,可以到裡面去查看。

問題 1: 發現有某個版本出現了重大問題怎麼辦?

假設你管理套件 gopher.live/ue0ddd4a99c02/proverb,目前已經發佈到了 0.2.0的版本出去。但是發現你這個版本有重大的問題。需要把這個版本撤回(或是下架),那麼你可以在套件的 repo 中輸入以下的指令:

go mod edit -retract=v0.2.0

這樣一來,就會發現 go.mod檔案變成以下的內容

module gopher.live/ue0ddd4a99c02/proverb

go 1.16

// Go proverb was totally wrong
retract v0.2.0

這時候,我們可以加上一些註解在 go.mod檔案內,這樣一來其他人要使用的時候,也會出現相關註解。

git add -A
$ git commit -q -m "Fix severe error in Go proverb"
$ git push -q origin main
remote: . Processing 1 references        
remote: Processed 1 references in total        
$ git tag v0.3.0
$ git push -q origin v0.3.0

透過以上方式,可以將版號推進一號。也已經把正確的內容修正好了。

如果其他人想要拉下有問題的版本,就會出現相關警告。

go get gopher.live/ue0ddd4a99c02/proverb@v0.2.0
go: warning: gopher.live/ue0ddd4a99c02/proverb@v0.2.0: retracted by module author: Go proverb was totally wrong
go: to switch to the latest unretracted version, run:
	go get gopher.live/ue0ddd4a99c02/proverb@latestgo get: downgraded gopher.live/ue0ddd4a99c02/proverb v0.3.0 => v0.2.0

這樣的方式,就可以透過這個方式來達到撤回版本的流程。

相關疑問:

  • 如果沒有執行 go get 來連接查詢,是不是沒有辦法取得版本撤回的資訊?
    • 沒有錯,目前依舊需要透過 go get或是 go list來取得資料。

相關學習資源


[學習心得][Golang] 簡單介紹幾個 Golang 1.16 的新功能

$
0
0

前言:

TL;DR

本篇文將要介紹:

如何安裝嚐鮮版本的 golang 1.16

如果你想要嘗試一下,還沒有在 Homebrew 上有支援的 Golang 版本,就目前 (2021/02/19) 狀況由於許多相關套件還沒有更新好,造就 HomeBrew 遲遲無法 Merge ,大家可以參考一下這個 PR

那如何在本地端安裝一下測試版本的 Go1.16 呢? 就如同本文開場圖片的敘述一下:

go get golang.org/dl/go1.16
go1.16 download

如此一來,就會在本地端安裝一個編譯好的檔案。 go1.16如果需要相關的測試可以直接跑 go1.16 build或是 go1.16 test來跑。

1.16 新功能主要列表

Apple Sillicon (也就是目前的 Apple M1 Chip) support

這個版本正式支援 apple Silicon 誒就是 64-bit ARM 架構。(a.k.a. Apple M1 chip) 。 可以透過 compiler 參數:

  • GOOS=darwin,
  • GOARCH=arm64

來設定,而原先的 iPhone binary 設定則改為:

  • GOOS=darwin,
  • GOARCH=ios/arm64

可以透過指令 env GOOS=darwin GOARCH=arm64 go build來編譯出給 Apple M1 的 binary 。

Go Module Retract

這部分可以參考我的另外一篇詳細文章。 [學習心得][Golang] Go 1.16 新功能的「版本撤回(下架)」(Go Modules retraction)

Embedding Files (把靜態檔案包含在專案中)

以往是無法將靜態檔案,包在 Golang 的專案之中。幾個方式只有:

  • 如果要載入的檔案是 json ,將它弄成變數。
  • 如果是 html 的 template 檔案,需要跟 binary 放在一起
  • 或是可以看一下 go-bindata的專案(相似的還有 packrpkger ),透過這個方式將 static file 放在專案中變成 resource 。

但是在 1.16 之後,可以正式支援了。

假設檔案結構為:

.
├── go.mod
├── main.go
├── static
│ └── css
│ └── main.css
├── templates
│ └── index.html.tmpl
└── title.txt

透過以下方式,可以將檔案打包到專案中:

以後要打包整個網站,不用在擔心 docker 打包的時候會忘記把 template 跟 image 資源檔案忘記打包。

相關資料

相關文章:

[好書分享] 創意競擇 - 蘋果前iPhone首席軟體工程師獨家告白

$
0
0
創意競擇 - 從賈伯斯黃金年代的軟體設計機密流程,窺見蘋果的創意方法、本質與卓越關鍵
Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs
作者: 肯.科辛達  
原文作者: Ken Kocienda  
譯者: 洪慧芳  
出版社:臉譜 
出版日期:2021/01/26 

買書推薦網址:

前言:

這一本是今年所讀完的第四本書。 當初也是聽到 「「現在開始你們都是鍵盤工程師!」iPhone 鍵盤的誕生與賈伯斯時代的蘋果軟體設計流程」的結果馬上就買了這一本書的電子版(週日買),作天晚上(週三)就看完了。 為什麼會這麼想要看這本呢? 我的理由如下:

  • 這是第一本由 「蘋果首席iPhone軟體開發工程師」(註解: Principle iPhone Software Engineer,通常在外商科技公司中, Principle Software Engineer 通常就是非管理職的最高職位)所寫的書籍。
  • 這也是一本講解有賈伯斯在的時候蘋果所產生出來的氛圍,還有一個好的功能是如何挑選出來的。

蠻推薦給大家看的,有興趣可以買來看。

內容簡介與心得:

──蘋果前iPhone首席軟體工程師獨家告白──
──Steve Jobs賈伯斯黃金時代蘋果創意法則全紀錄!──

蘋果產品全球有近二十億使用者,但催生、實現這些創意的所有工作流程,
由於內部嚴格的「保密條款」限制,始終成謎。
天才們究竟是如何孕育出iPhone、iPad、Safari……?
蘋果前首席軟體工程師,首度揭露賈伯斯黃金時代的蘋果設計開發流程,以及成就Apple的關鍵要素

章節條列

  • Introduction前言
  • The Demo演示
  • The Crystal Ball水晶球
  • The Black Slab黑色方碑
  • One Simple Rule大道至簡
  • The Hardest Problem最難的問題
  • The Keyboard Derby鍵盤大賽
  • QWERTY英打鍵盤QWERTY
  • Convergence聚合
  • The Intersection交會點
  • At This Point此時此刻
  • Epilogue後記

整本書從一個 iPad 的鍵盤設計展示開始(也是作者最後一次在公司看到賈伯斯),慢慢回想到作者如何被找來蘋果開發軟體。 如何協助開發 Mac 上面的瀏覽器,也是因為瀏覽器的開發讓作者第一次感受到十倍工程師的能力。裡面的小故事是: 一開始作者想透過 Mozila 的原始碼修改移植到 Mac OS 上面。但是因為 Mozilla 實在太龐大了,所以導致作者花了六個禮拜還不能讓 Mozilla 在 Mac OS 上面正確的執行(應該說連編譯 compile 都不行)。 但是新成員查理的加入,他用了兩天的時間就就透過自己寫的一層 Shim 讓 Mac OS 能跑 KDE 上面的瀏覽器(Shim 是一層欺騙層,一方面騙 KDE 瀏覽器正在 KDE 上面,一方面騙 Mac OS 他跑的是 Mac 軟體。 (類似 Kubernetes 裡面的 Dockershim )

這也是一個很特別的故事分享(原來強者可以兩天內寫好一個 shim 啊啊啊啊啊)

完成了 Mac OS 上面的瀏覽器(也就是我們後來熟知的 Safari ),作者有機會能高升為 iCloud (當時還是網路儲存),但是因為自己的不適應,竟然用跳槽威脅老闆們要當回工程師。(這也是很有趣的例子,原來真的有人願意單純當工程師)。 然後作者也加入了後來的 Purple 團隊(也就是蘋果最偉大的產品 iPhone)的團隊。 也是這個機會讓後來作者能有機會能夠在賈伯斯面前 demo 新功能「鍵盤的功能」。 現在 iPhone 上面的鍵盤就是作者參與製作的功能,並且也是作者打造出的自動拼字的功能,也是他打造出手指調整。也就是按鈕按下去得時候,往往使用者以為是指尖按到,但是往往會是指腹會先碰到螢幕。造成使用者以為不精準(其實是自己先碰到),連這個都能改善,真的是蘋果啊!!

心得:

蘋果的許多展新功能不是透過許多人的腦力激盪,而是透過許多不同的展示。許多有天賦的工程師透過高效率的樣品與展示,讓賈伯斯與許多高層能夠透過展示的成果決定那些功能是不是蘋果需要的功能。 這些段落在書中有詳細的敘述,也是很值得看的段落。身為工程師能了解如何做高效地展示,並且如何在展示的途中思索如何讓許多人能接受自己的展示。都是很重要的能力。

想要快速了解書內容,可以聽聽 Podcast 。但是身為工程師的話,建議一定要看本書。

參考文章

[學習心得][Golang] 舊的開源專案開啟 Go Modules 可能會遇到的問題 (e.g. go get 無法更新版本)

$
0
0

前言:

各位好, LINE Bot Go SDK 是一個經營超過了五年的專案,並且版本號碼也早就已經到了 v7.8.0 。

而本月月初 (2021/April) LINE Bot Go SDK 又有新的版本更新了,這次有支援到三月平台所提供新的功能,還有將去年公開的 FLEX Msg 的 update 2 更新了。歡迎大家使用。

這個套件已經更新到 v7 版本,才支援 Modules 。 結果一開啓就踩到雷,感謝台灣的網友 wys1203 送了 PR 修復。 我也整理一下相關心得,跟大家分享一下。

TL;DR

本篇文將要介紹以下一些的部分:

如何將舊的開源專案支援 Go Modules

LINE-BOT-SDK-GO 是 LINE 開源出來的對於 LINE Messanging API 所釋放出的開源套件,並且支援多個語言版本(Go., PHP, Java, Python) 。

原本這個 https://github.com/line/line-bot-sdk-go 的版本已經超過 v7 ,但是遲遲沒有支援 go modules 。 也就是並沒有 go.mod在該專案的檔案下面。所以需要透過以下方式來啟動 Go Modules (Enable Go Modules)

- go mod init
- go mod tidy
- go mod vendor

原本 PR 看起來也沒有太多的問題,於是就將新版本發佈出來。 (v7.9.0)

發生問題了

原本版本更新後,看起來也沒有太多問題。但是版本更新後卻發生了以下兩個問題:

無法更新版本 (Cannot update version by “go get”)

這時候我試著去更新一個本來有使用到 https://github.com/line/line-bot-sdk-go 的套件,正常的更新流程如下:

>> go mod tidy                                                           
go: finding module for package github.com/line/line-bot-sdk-go/linebot
go: found github.com/line/line-bot-sdk-go/linebot in github.com/line/line-bot-sdk-go v7.8.0+incompatible

問題出來了,我明明有更新版本到 v7.9.0但是卻無法抓到最新的版本?

於是我拿了一個新的專案,重頭試試看。

  1. Copy https://github.com/line/line-bot-sdk-go/tree/master/examples/echo_bot to your go path
  2. go mod init
  3. go mod tidy

結果一樣是出現:

>> go mod init                                                                       
go: creating new go.mod: module github.com/kkdai/echo_bot 
go: to add module requirements and sums:
	go mod tidy
 
>> go mod tidy                                                                            
go: finding module for package github.com/line/line-bot-sdk-go/linebot
go: found github.com/line/line-bot-sdk-go/linebot in github.com/line/line-bot-sdk-go v7.8.0+incompatible

大家可以參考這個 issue。 不論使用 go get還是使用 go mod tidy都無法順利將版號更新的最新的版本。 這個問題,讓我困擾了一陣子。

pkg.go.dev  上面版本是舊的

<a id=”go-dev-out-of-date””></a>

先來稍微解釋一下 https://pkg.go.dev 是一個 Golang 社群的套件說明網站。開發者可以透過關鍵字搜尋套件,並且可以查看相關的說明(所有內容都是根據 github.com 上面的資訊)。

而透過 https://pkg.go.dev 也可以很輕鬆的查許多專案版本方面的資訊,比如說 https://pkg.go.dev/github.com/appleboy/gofight 可以看到有最新版本 v2 - https://pkg.go.dev/github.com/appleboy/gofight/v2

雖然 https://github.com/line/line-bot-sdk-go 已經加上了 go.mod的檔案,但是卻無法找到 https://pkg.go.dev/github.com/github.com/line/line-bot-sdk-go/v7 這個資料夾。

這時候感謝台灣網友提供的 Pull Request 提供給我相關的想法。

Go Modules 對於 v2 之後的支援方式

根據官方的文件 - Golang-Blog Publishing v2 and beyond上面有提到,如果需要發布 v2 之後的版本由於是具有不向後兼容的方式。 所以在發布得時候,官方建議有兩個方式:

  • 建立一個新的資料夾 v2並且把東西全部更新到該資料夾上面。並且更改 go.mod將版本號碼改成 v2
  • 或是直接更改目前資料夾的 go.mod將版本號碼改成 v2

修改 go.mod 檔案到 v2 (或是之後)的方式

$ go mod edit -module github.com/YOU/YOUR_PROJECT/v2 go.mod

這邊要注意,因爲 go mod init並不會自動幫你加上相關的版本(如果超過 v2),只得自行加上。所以需要「手動」加上相關的版號,也就是說如果你的套件可能已經超過了 v2以上,但是一直沒有啟動過 go modules 那麼你可能就會踩到這個雷。

如何修復? 有用到的人該如何修改?

原始套件啟動 Go Modules 的修復方式

關於 https://github.com/line/line-bot-sdk-go 的修復方式,大家可以參考這個 pull request

使用到的套件,要如何能夠正確的更新版本?

如果你是使用 https://github.com/line/line-bot-sdk-go 這個套件的人,請根據以下方式來正確地取得最新的版本。

  1. 所有 import 的地方,修成到 v7

    1. AS-IS: import "github.com/line/line-bot-sdk-go/linebot"
    2. TO-BE: import "github.com/line/line-bot-sdk-go/v7/linebot"
  2. 重新修改 `go.mod. 透過執行

    1. go mod tidy
    2. go mod vendor
  3. 測試你本地端的程式碼,確定沒問題。

  4. 更新到 GitHub

結論:

因為 Go Modules 其實是兩年前的 1.11 才開始使用,但是許多專案其實也沒有馬上啟動。 如果沒有啟動 Go Modules 其實版本更新也不會出錯。 但是只要一啟動 Go Modules 的話,就要小心本篇文章所提供的相關案例。

其實啟動 Go Modules 是相當方便的,也應該要提早準備好相關的修正。希望每一個套件管理者能儘早的準備升級到 Go Modules 的套件支援。

相關文章:

[好書分享] 無限賽局(The Infinite Game)

$
0
0
無限賽局 - 翻轉思維框架,突破勝負盲點,贏得你想要的未來 THE INFINITE GAME

作者: 賽門.西奈克  
原文作者: Simon Sinek  
譯者: 黃庭敏  
出版社:天下雜誌出版 

買書推薦網址:

前言:

這一本是今年所讀完的第五本書。賽門,西奈克(Simon Sinek) 一直是我很喜歡的作者,我似乎也買了(讀了)他的不少創作,從『先問為什麼」,到這一本書。

這一本書本來認為是講解有限思維與無限思維的書籍,但是有不少關於公司經營策略的方向。 如果公司透過了有限思維來制定公司的願景,那麼公司的前景是堪憂的,相反過來許多的公司都透過「無限賽局」的思維來訂定的公司的目標企業形象。這樣一來不僅僅能夠帶來源源不絕的動力,對于公司的進步也是可以期待的。

對於代表公司在外頭常做企業形象演講的我,這樣的思維是相當的重要的。這本書也蠻推薦給常需要代表公司在外頭演講的相關職業。

最後獻上天下雜誌所製作的推薦影片,其實蠻讚的。

內容簡介與心得:

《先問,為什麼?》暢銷作家賽門‧西奈克最新顛覆力作

黃金圈引導你找到最初的為什麼
無限思維為你重新定義工作與人生的方向與策略

贏了對手讓人士氣大振,但是為什麼興奮兩天就消散?
終於站上市場第一,但是新競爭者不斷出現,什麼時候才是真正的勝利?
在競爭中,我們怕輸、怕落後,拼命的像滾輪上不停奔跑的老鼠,疲憊不堪。
這是我們唯一的選擇嗎?

市場沒有一定規則,思維框架決定了你的策略選擇。
不被當下成敗綁架,才能主動應變,每天都充滿動力!

我們被自己的思維框架困住了!
習慣用贏家輸家、成功失敗的角度來看事情,
是讓我們不斷感到挫折、無法持續努力的最大盲點!

商業環境不是球賽棋局,改變規則沒有預告、參賽者沒有名額限制,也沒有一定的終場時間。

人生也是如此。

章節條列

  • 作者序 我為何寫這本書
  • 前言 怎樣才算勝利?
  • 01 有限賽局和無限賽局
  • 02 崇高的信念
  • 03 如何找到信念
  • 04 讓信念傳下去
  • 05 企業責任2.0
  • 06 意志與資源
  • 07 信任的團隊
  • 08 小心道德褪色
  • 09 可敬的對手
  • 10 攸關存亡的應變
  • 11 領導的勇氣
  • 後記 名為人生的賽局

就如同影片說明的,作者對於目前的企業文化覺得有些怪怪的。自從作者讀了五十年後的 1986年,卡爾斯寫了《有限賽局與無限賽局》(Finite and Infinite Games) 之後,他知道許多問題的癥結點在於許多的企業都使用者「有限賽局」的思維作為企業文化的表徵。

在這本書一開始先敘述「有限賽局」與「無限賽局」的不同,主要的思考論點也在於「有限賽局」的思考脈絡始於競爭,但是就算很順利的將公司的達到了市場的領頭羊,或是市場上第一佔有率的公司。接下來又該如何? 這樣的思維往往是相當危險的,代表公司的創辦人本身看到的並不是公司未來的發展。就如同本書提到的,公司發起的主要因素一定是為了賺錢,但是如果只是將賺錢來當作公司主要核心目標甚至是公司標語的時候,那麼公司的未來是岌岌可危的。

因為往往賺到了許多前後,公司可能接下來就是精簡支出,以求取更高的獲利。為了讓股東賺取更多的獲利,而不在意是否能夠找到公司的信念。

但是每間公司並不完全能夠遵守的無限賽局的想法,很多時候許多公司一開始都是由著無限賽局的夢想而出發。 但是隨著與競爭者的相互競爭下,許多公司會迷惘,進而失去了無限賽局的思路,讓自己公司陷入了有限賽局的迷惘內。

這種往往發生在許多團隊中的「道德褪色」,指的是因為團隊間的惡性競爭,造就了欺騙甚至是假報成果的狀況。 書上也指出就算是在紀律嚴明的軍中,也會因為當局者陷入有限賽局的思路,每次只想著如何贏過其他的競爭對手來取得更好的成績,而與許著軍中出現了所謂的道德褪色的狀況。

「無限賽局」的思維並不容易,往往許多時候也會造成痛苦的轉變過程。 作者先舉了反向的例子,也就是「發明數位相機專利的柯達」,最後竟然就是被數位相既的風潮導致公司破產。 因為當初第一位發明數位相機專利的人,其實是柯達裡面的員工。但是當時的柯達高層,還是汲汲營營與底片的收入,認為底片才是柯達收入的主要來源,數位相機不會變成風潮。所以刻意打壓,申請了專利也只是拿來收取專利授權金而不是自己開發數位相機。到了數位相機得專利過期後洶湧而來的數位相機風潮就讓柯達支撐不下去,緊守著底片的他們也跟不上新的浪潮,只能走向破產的收場。

接下來作者也舉了具有公司信念的例子,比如說全美國最大的藥局 CVS 連鎖藥局,在 2014 年決定了下架了菸類的商品。 因為他們真正在護著客戶的健康,也了解販賣著真正下架香菸才能讓他們的顧客真正的健康。但是這樣的轉變一開始受到華爾街投資客的不看好,認為下架香菸商品會讓 CVS 的「每股獲利大幅度減少」,更讓整個企業走向衰敗。

但是事實上,許多的顧客樂於見到這樣的企業轉變。紛紛轉向CVS 去購買其他健康的商品。並且許多在 CVS 藥局工作的人也能夠以此為榮。真正的實現他們的口號「幫助人們變得更健康」。 這樣的企業口號變得更加的真實,也讓許多競爭者望塵莫及。這樣才真正是所謂的「無限賽局」的思維。

參考文章

心得:

Simon Sinek 真的很會激勵人心,就算只是在書上的文字。我剛看完 CVS 藥局那個段落的時候,真的是相當的激動也相當的感動。 真正的企業形象的塑造,在於如何透過一個簡單而由上往下的行動來塑造整體的企業文化。不要讓許多企業經營的原因影響了許多原本立意良好的企業初衷。 身為公司的技術傳教士,經常思考著如何能夠協助公司打造更好的技術品牌的同時。 回過頭來也常常想到,許多的上位者其實都帶給我們許多好的影響。 記得在日本總部受訓的時候,總部的技術長總是百忙之間抽空來跟新建同仁們聚餐,並且會儘量跟每一個同仁講到話。也希望每一位同仁能夠真正地做到「Be Open」,讓同仁們能夠更加的相互溝通。 這些事情也都是我經常忽略,應該要把這些小故事更經常地放在我的表現之中,希望每一個夥伴能感受到。

如果你也是要打造公司形象的行銷夥伴,或是也是技術傳教士。這一本書真的會讓你充足滿滿的能量。

[TIL][Android] Android Studio 開啟專案可能會遇到的問題

$
0
0

前言:

最近 Google Taiwan 開啟一個計畫「Android App 開發培訓計劃 2021」,透過 Android Studio 跟著 Kotlin 這個語言來讓大家寫 Android App 。雖然我之前有寫過,但是也很久沒使用 Android Studio 了,來開啟專案看看吧。 不過一開始好像開啟錯誤的 codelabs www 不小心開到後面的 Use Kotlin Coroutines in your Android App,出現了一些問題,也順便解決一下。

如何設定環境(How to setup your Android 4.1 on Mac Catalina)

跟著這次的 Kotlin coroutine codelab 你會找到 Android Studio 下載的地方。 你也會找到相關的 github for Kotlin coroutine。 然後透過 Android Studio 來打開 coroutines-codelab的資料夾,你可能會出現以下的 Error 。

> License for package Android SDK Build-Tools 29.0.2 not accepted
> License for package Android SDK Platform 29 not accepted.

> Could not resolve all dependencies for configuration ':start:debugRuntimeClasspath'.
> Could not create task ':start:minifyReleaseWithR8'.
> Cannot query the value of this provider because it has no value available.

原因:

因為最新版本的 Android Studio 4.1.3 ,預設使用的 Android SDK 版本是 30 ,但是這次的 codelab 是使用舊版本的 29 來準備的。所以需要下載舊版本的 SDK 並且同意相關的 License 授權。

解決方式:

[Preference] -> [System Setting] -> [Android SDK] -> Enable Android Platform 29

這樣下載 Android SDK 29 的時候,就會同時去同意 License 。 就可以正常的 Compile。 範例也可以正常執行在 Android Simulator 上才是。

相關文章:

[TIL][Kotlin] 關於 Kotlin 相關語法快速整理

$
0
0

前言:

最近 Google Taiwan 開啟一個計畫「Android App 開發培訓計劃 2021」,透過 Android Studio 跟著 Kotlin 這個語言來讓大家寫 Android App 。趁機順便學習一下 Kotilin 相關語法跟需要注意的地方。

相關工具

Kotlin Playground

由於有點懶得安裝環境跟相關的 IDE 設定,所有的練習其實可以快速的在 Kotlin Playground上面完成。

語法Tutorial - Koans

可以透過網頁上面的 Koans或是內建在 JetBrains IntelliJ IDEA or Android Studio 的 JetBrains educational plugin

學習建議:

由於這個語言我不是很熟習,但是熟悉新的語法其實蠻建議透過 Tutorial 來先有個概念性的了解,方便你開始相關的查詢。 所以這邊建議先跑過一次 Koans再來把相關資料結構與語法來做一個語法的相關脈絡整理。

特別資料結構語法說明

LIST

val numbers: List<Int> = listOf(1, 2, 3, 4, 5, 6)

透過 List關鍵字來加上 generic type 來建立出相關 List 物件。也可以透過 Inferred 方式建立。

val numbers = listOf(1, 2, 3, 4, 5, 6)

Kotlin 是 Zero-based Index 的語言(延伸自 Java) 。

MutableList

參考官方文件, MutableList 為長度可變的 List 。也就是可以針對 List 去 add, addAll, listIterator, remove, removeAll… 相關操作。 宣告方式參考如下:

val entrees = mutableListOf<String>()

相關文章:

[學習心得][Golang] 如何透過 Golang 開發 OAuth2 的 PKCE - 以 LINE Login 為例

$
0
0

前言:

在 2021/04/09 的新聞上, LINE Login 正是支持了 PKCE (Proof Key for Code Exchange) 的流程。 本篇文章將清楚地解釋一下,什麼是 LINE Login ? 為何 LINE Login 需要支持 PKCE ? 最後會透過一個範例,帶領著讀者們一起來導入與體驗 LINE Login with PKCE 。

其中本篇文章的程式碼分為三個部分,以下快速說明:

TL;DR

本篇文將要介紹以下一些的部分:

什麼是 LINE Login? 什麼又是 OAuth 2.0 ?

許多的商業服務都會透過會員機制來提供許多專屬的優惠或是獎勵活動,但是會員的註冊與登入流程常常讓許多使用者覺得為難。除了要填寫許多的資料外,使用者還需要額外記住另外一組的帳號密碼。 LINE 在台灣的佔有率相當的高,並且幾乎每個使用者都有 LINE 的帳戶的狀況下,這時候如果能夠直接使用 LINE 帳戶來註冊與登入網站服務的話是不是相當的方便?

LINE Login 除了提供一個方式來登入之外,也可以提供使用者名稱,大頭照的相關資訊。並且透過 LINE Login 也可以同時讓使用者加入商業服務的 LINE官方帳號,讓使用者更無時無可都可以使用到相關的服務。

什麼樣的情況會建議使用 LINE Login

這裡會條列出哪些情況建議需使用 LINE Login 作為讀者來評量自己有沒有需要使用 LINE Login :

  • 剛開始要建立電子商務服務或是網站,想要減少使用者註冊的時間並且快速加入。
  • 想要推廣自身官方帳號的聊天機器人服務。
  • 就算是已經推廣一段時間的電子商務服務,但是想要透過 LINE 來接觸不同的客戶群。

了解為什麼使用 LINE Login 以及甚麼狀況下建議使用之後,接下來就引導讀者如何使用範例程式碼

範例程式碼

https://github.com/kkdai/line-login-go

測試網站

https://login-tester-evan.herokuapp.com/

如何部署範例程式碼:

  • LINE Developer Console建立相關的 Provider 跟 Channel。
  • 建立一個 LINE Login 的帳號,並且將以下兩個資訊記住:
    • Channel ID
    • Channel Secret
  • 另外建立一個 LINE@並且打開 MessageAPI 的功能(也就是建置 chatbot 用),並且將以下兩個資訊記住:
    • Channel Secret
    • Channel Token
  • 到 https://github.com/kkdai/line-login-go 按下 Heroku Deploy ,建立該帳號並且部署該服務。這時候會要輸入三個資訊:
    • LINECORP_PLATFORM_CHANNEL_CHANNELID
      • 填入 LINE login channel ID
    • LINECORP_PLATFORM_CHANNEL_CHANNELSECRET
      • 填入 LINE login channel Secret
    • LINECORP_PLATFORM_CHATBOT_CHANNELSECRET
      • 填入 Chatbot channel Secret
    • LINECORP_PLATFORM_CHATBOT_CHANNELTOKEN
      • 填入 Chatbot channel Token
    • LINECORP_PLATFORM_SERVERURL
      • 這個資訊根據你的 heroku app 名稱來決定,假設你的 Heroku app 名稱叫做 test-api-1234那麼你就該填 https://test-api-1234.herokuapp.com
  • 回到 LINE Login 的帳號設定,[App setting] 將以下位置寫入 callback URL https://test-api-1234.herokuapp.com/auth
  • 回到 LINE chatbot 的帳號設定,記得把 https://test-api-1234.herokuapp.com/callback加到 LINE chatbot web hook 才能正確地啟動聊天機器人。

LINE Login 的流程

(使用 Profile (也就是 OAuth 2.0) 方式來讓使用者透過 LINE Login 之後取得使用者資訊)

LINE Login 提供了兩種方式來讓開發者可以安全地取得使用者資訊:

兩種方式的不同點在於開發者可以再請求 scope的時候標注是透過 openid或是 profile方式來索取相關資訊。

以下的內容均參照 Integrating LINE Login with your web app

  • (1). 首先瀏覽器訪問該網站 (假設你直接使用 https://login-tester-evan.herokuapp.com/),進入了 browse()顯示出三個 LINE Login 按鈕。
  • (2). 使用者按下了 LINE Web Login 的話,就會進入 gotoauthpage()直接產生一組 API URL 直接導向到 https://access.line.me/oauth2/v2.1/authorize。這邊其實有一些參數可以設定,可以參考 LINE Login 參數設定
  • (3). 使用者這時候會連到 LINE Platform 來進行登入的步驟,不論是透過 App 登入還是輸入帳號密碼的登入方式。登入完成後會透過 redirect_uri網址的位址傳回一組 code ,作為使用者資料的存取之用。 這時候會呼叫到 auth()來解析 code 。
  • (4). 在同一個 auth()之中解析 code, state, 與 friendship_status_changed 後,檢查 state 正確性之後。就可以透過 code 去抓取使用者的資料了。 這時候會呼叫 https://api.line.me/oauth2/v2.1/token的 API ,相關必要參數也可以參考這個網址
  • (5). 一樣在 auth()之中,回傳的結果可以得到 id_token ,透過 id_token 需要透過解譯的方式來將它還原成使用者的資料。這邊也已經包裝好為 DecodeIDToken()
  • 透過 DecodeIDToken()就可以得到使用這名稱與大頭照。 (email 需要額外申請)

以上就是一般的電子商務網站的導入流程。

OAuth2 有什麼樣的缺點

在 OAuth2 提出後, Google 也在 2015 Google 提出的 RFC 7636中也提出了一些值得考量的點。 本篇文章有提到在手機端的 App 如果導入了 OAuth2 的流程中,有可能傳輸過程中被其他惡意安裝的手機 App 竊取相關資訊。 相關細節可以參考 LINE Login 官網提供的詳細案例

(詳細說明,請參考 Benefits of implementing PKCE for LINE Login)

這裡稍微跟大家說明相關的流程與發生的問題:

  • 使用者透過手機上有串接 OAuth2 的 App 來做 Authorization
  • 進入 OAuth2 服務提供商的帳號登入畫面
  • 認證完成後, OAuth2 坪台商會根據當初登記的 URL (手機上為某個登入的 URI Scheme) ,開啟相關 App。
  • 這時候,如果有使用者不小心安裝了惡意的 App ,他可以登記同一個 URI Scheme ,但是因為手機設計原理兩個 App 都會收到相關的 URI Callback 。
  • 惡意程式(Malicious App)收到 URI Callback 呼叫並且取的 codestate並且透過其他方式取得 Channel ID 跟 Channel Secret (原理透過 App 掃瞄,這裡就不詳細敘述)。
  • 這時候,取的 codestate的惡意程式,就可以透過呼叫 GetAccessToken取的相關 Token 並且獲得權限。

由於原先的 OAuth2 在 client App 端有這樣的缺陷,所以透過 PKCE 的方式可以來補救相關問題。

什麼是 PKCE?

(from LINE Login 導入 PKCE in LINE Login 的流程示意圖)

PKCE (Proof Key for Code Exchange) 是由 Google 在 RFC 7636提出的 Code Exchange 機制,透過這樣的交換資訊方式。可以避免中間透過 Callback URI 所造成的竊取攻擊。 詳細的方式敘述如下:

先解釋兩個參數:

  • Code Verifier: 一個特殊字串,長度限制為 43 ~ 128 之間。
  • Code Chanllenge: 透過 SHA 256 將 Code Verifier轉換過的字串。

接下來要解釋一下,這兩個字串如何能夠讓 OAuth2 的流程中安全性增加。由於 SHA256 是不可逆且較安全的加密模式,並且在資料的傳輸上先提供 Code Chanllenge再來是 Code Verifier可以確保著交握的兩端都是同一個人,因為必須要同時都有兩個才能正確地確認。 這樣就算原本的 code被竊取到了,也會因為無法產生正確的 Code Verifier讓惡意程式無法竊取到資料。

那麼詳細的 LINE LOGIN withg PKCE流程如下:

  • 產生 Web Login URL 的時候,先丟 Code Chanllenge在傳遞參數中。
  • 連接到 LINE 開始認證流程,完成認證流程後。透過 Callback URI 傳回 codestate
  • 這時候認證方會將 Code Verifier送給認證伺服器來取得 Access Token 。
  • 認證伺服器端會拿 Code VerifierCode Chanllenge來確認,是否是同一個需求端發出的需求。
  • 返回 Access Token,完成認證跟取得資訊的需求。

如何在 LINE Login 之中導入 PKCE?

接下來會使用 line-login-SDK-go 與 LINE-login-pkce-go 兩個範例程式碼來展示:

如何產生 Code Verifier

如何產生 Code Challenge

文件上面有提供 Code Challenge 的 python psuedo code,這邊將其轉換成 Golang 的程式碼。 主要比較複雜的部分是 sha256.Sum256()跟字串要做 URLEncoding 處理。 主要要根據 Base 64 Encoding with URL and Filename Safe Alphabet (opens new window)的處理方式來做。 其實在 Golang 只要一行就可以搞定了。

產生 Web Login 網址

這一段程式碼則是利用 github.com/kkdai/line-login-sdk-go所產生的網頁轉址的程式碼,主要就是產生 codeVerifiercodeChallenge (Global 參數)。請注意,在 SPEC 中,每一個 Web Login request 的 codeVerifiercodeChallenge都需要是不同的,才能確保資訊的安全。

要求 Access Token 的程式碼修改

這裡只需要注意的是, codeVerifier需要傳遞正確的,不需要重新產生即可。

展示

(展示影片來自網站: PKCE LINE Login Test Site)

這邊有個簡單的展示網站,也歡迎想了解如何開發的開發者們,可以直接使用以下的開源程式碼。 範例程式碼提供兩種模式的來取得使用者的登入資料。

  • OpenID: 透過 OpenID 的格式,直接登入完成後,取得使用者登入資訊的 JWT 。並且提供相關解析的程式碼。
  • GetUserProfile: 透過取得 User Access Token 的方式,呼叫 Get User Profile 來取得登入使用者的資訊。

更多的程式碼,歡迎參考。

LINE Login PKCE Starter:

結論:

許多開發者在開發 Web App 的時候,最麻煩的往往是使用者資料的註冊。 因為複雜的註冊流程與多一個帳號密碼往往會讓使用者卻步。 LINE Login提供良好的機制可以讓許多開發者使用到國內最多人使用的 LINE 來登入,節省掉許多開發上的麻煩。 本篇文章介紹了新的登入機制: PKCE for LINE Login 。 讓登入機制符合最新的安全機制外,更可以讓使用上沒有開發後顧之憂。 並且提供相關範例程式碼,讓開發者可以無痛的導入最新的機制。

相關文章:


[TIL][Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論

$
0
0

前言:

疫情升溫打斷本來出遊計劃,還好女兒很乖在玩。 那我就來弄弄 Jekyll 的評論搬遷,結果發現最近有個好用系統 utteranc.es 可以讓你直接使用 github issue 來作為文章評論。 來看看吧。

本篇文章將告訴你如何移出,並且使用 Github Comment 作為文章評論用,現在也有個開源好用的工具。 https://utteranc.es/

什麼是 Disqus

一直以來本站是透過 Jekyll 來架設的,之前本來有使用 Disqus 作為文章評論系統,雖然很多人說廣告太多,太慢。只是覺得還好,可能沒仔細看。 最近覺得 disqus 的廣告越來越嚴重,影響整個效能。決定拿掉了。 有需要參考的可以看一下這個 commit主要就是先註解掉相關的設定。 然後發送 git push 即可。

移除 diqus

大家可以參考這個 commit. https://github.com/kkdai/kkdai.github.io/commit/3dfba4885874cb1cb0c06a09fd2f4fffd892623a

主要就是把 disqus 的設定拔掉。

highlighter: rouge
markdown: kramdown
#disqus: evanlin1007

#comments :
#    provider : disqus
#    disqus :
#      short_name : evanlin1007

加入 utteranc

utteranc 是一個完全 Open Source 並且使用 github comment 。並且提供一些設定,還有外觀的 theme 可以設定。感覺相當好用,社定上也很簡單:

  • Install for your github app
  • Put code in your Jekyll
  • Done ! (搭啦)

參考 https://github.com/kkdai/kkdai.github.io/commit/b9606abd93c08bf131efa4db78c8762e8a26f1da 可以修改 _layouts/post.html如下:

<script src="https://utteranc.es/client.js"
        repo="kkdai/blog"
        issue-term="pathname"
        theme="github-light"
        crossorigin="anonymous"
        async>
</script>

完成品:

這樣是不是很快速(五分鐘就好了)

代辦事項:

接下來就要把 disqus 的評論搬到 github comment, 這邊可以先 export 出來後,寫個 Golang 來 import 。找到了在這裡: http://disqus.com/admin/discussions/export/

接下來就是把文章評論搬過去。

參考文章:

[好書分享] 什麼時候是好時候:掌握完美時機的科學祕密

$
0
0
什麼時候是好時候:掌握完美時機的科學祕密
When: The Scientific Secrets of Perfect Timing

作者: 丹尼爾・品克  
出版社:大塊文化 
出版日期:2018/05/29 

買書推薦網址:

前言:

這一本是今年所讀完的第六本書。你知道透過大數據統計的狀況下,大部分的人什麼時候喝咖啡最好? 什麼時候做文件處理的事項最好? 什麼時候是最容易發生轉職跟轉換工作的季節? 這本書分享了許多統計上的相關數據,讓你了解時間所帶來的秘密,並且也根據每個人工作上的習慣,來建議什麼時候做回覆電子郵件的事情最好,什麼時候建議拿來開會與發想事情?

這本書作者之前看過他的書: 動機、單純的力量(DRIVE: The Surprising Truth About What Motivates Us),所以對於他這一本書相當的期待。

內容簡介與心得:

我們無時無刻都面臨一連串永無止盡、與「時機」相關的決定。什麼時候換工作,什麼時候安排課程,什麼時候步入穩定關係或全心投入專案。然而,我們卻隨意做出這些決定——基於直覺、預感及猜測。在本書中,丹尼爾.品克認為這是完全錯誤的方法。

根據品克的話,我們都知道時機就是一切,但我們對時間本身卻了解不多,以為時機是種藝術。他在書中表明,時機其實是一門科學,於是寫出這本談論「什麼時候做什麼事」、有關「時機」的書,為我們揭開時機的科學祕密:

•早上何時喝咖啡最好?——不是起床後立刻喝,最好的時間點是在起床後1~1.5小時喝。
•工作多久應該休息一下最有效?——每工作52分鐘,休息17分鐘。
•包含新年元旦,一年當中你有幾天可以重新開始?——86天。
•怎樣利用一天中隱藏的模式來建立理想的工作時間表?
•為什麼有些特定類型的休息,會顯著提高學生的考試成績?
•什麼時候是辭職、轉職、或結婚甚至離婚的理想時間?

品克借鑑心理學、生物學、神經科學和經濟學等豐富的研究成果,提煉精華,彙整成引人入勝、深具說服力的文章,字裡行間充滿魅力無窮的故事,以及實用的要點——集結在每一章的「時間駭客指南」中。本書富含宏大觀念與深遠寓意,將改變你對自己過去、現在及未來的想法,同時助你掌握人生各階段面臨時機抉擇的最佳決策。

章節條列

第1部 一天

首先透過心理學與生物學的角度來分析,上班族一天的情緒波動。會發現中午吃飯是一個很大的分界點。許多的人專注度在上午最高,但是中午吃完飯回來辦公室後,就開始逐漸下降到下班才會回覆。 還有快樂的心情也是如此,透過這些方式來提供給讀者們知道,該如何尋找人開會,該如何將工作事項做有效的排列與準備。

接下來透過慕尼黑時間型態問卷 (https://www.danpink.com/MCTQ/) 來判別每一位讀者屬於哪一種的人,那麼這樣來說他一天得時間會如何安排。

  • 雲雀
  • 第三種鳥
  • 貓頭鷹

其中雲雀是指的是早起的人們,而貓頭鷹完全相反的是晚起的人們,最後一種就是介於其中的人(大部分也是第三種)。

接下來探討的中午休息(午睡)帶來的工作相關影響,這部分蠻有趣的,其中午休可以帶來下午的充沛活力也是不能不注重的。其中建議的就是小睡 10 ~ 20 分鐘是最建議的休息長度。 下午之後,也建議有所謂的「微休息」,讓專注度可以快速地透過休息後來回復。

第2部 開始、結尾與中場

開始:

將時間從一天放長一點,放到整個職涯,整個人生或是幾年來說。什麼時候會是最被重視的時間? 就是一個新的專案的啟動,一個學習開始,甚至是一個新的工作的開始。 本書作者相當建議讀者要做「事前的驗屍」,也就是在一開始先訂定專案的成功,失敗的可能性,先預想各種可能發生的大型危機。

中場:

人們總是習慣在一開始的時候戰戰兢競,但是過了一半之後就出現了所謂的「中間點危機」(放大到人生,叫作中年危機)。 本書也分享了哪一些時間容易發生轉職的危機,中間點容易發生疲倦與厭煩感是既定的事實,該如何調適也是一門大學問,作者有其他建議方法:

  • 設定暫時性目標: 將中間幾個點設定成小目標,全力衝刺。
  • 公開宣示暫時目標: 告訴其他人你將要完成事項,讓大家一起來給你壓力,讓你能夠做完它。(這也是我最常使用的方式,笑!)
  • 話說到一半就停:這邊說得是,你不要把中間事情做到一個段落,而是每一件事情都做到一半,才會讓你有繼續的動力。
  • 不要讓鏈子斷掉: 回頭看看你過往的努力,會讓你更有信心跟毅力能夠往後。
  • 想像這麼做可以幫助其他人: 往往許多事情是不是只有你自己,很多時候你的工作會帶給其他人很深遠的影響。

結尾:

人們對於中年後的朋友開始去蕪存菁,也會慢慢對於自己想要深交的人開始篩選,這些都是結尾容易發生的事情。 甚至也分享了許多人在工作的最後幾天也往往最讓人印象深刻,甚至是人生的末期也讓人印象深刻。 所以結尾的力量其實相當的重要且深遠。 其中有句話我印象很深刻:

皮克斯每一部的電影主角都有一個想要達成的目標,但是他會明白這個目標其實不是自己需要的東西。而這個目標往往會讓他放棄他需要的事情:朋友,家人。最終主角都會放棄原來的目標,真正的追求他們原本就擁有的東西。 結果層次最高的情就是在這些背後的心理轉折。核心在於這種錯中複雜的情感。

第3部 同步與思考

接下來探討的是群體的時間點,同步與思考的部分。 要如何在整個團體能夠同步到一個最佳的狀況呢? 比如說合唱團要如何抓準時間表演? 龍舟隊伍要如何才能同步大家划船的力量往前衝刺? 擴大到整個組織要如何抓到好的時間點。讓整個團隊能夠在合諧的狀態?

首先作者介紹了一個印度的奇特行業: 幫人送新鮮的午餐便當到手上的工作,在印度首都有許多的人,到每一個人家中收取剛剛包好的便當,送到工作人員的手中。這些人代表的中午吃飯的重要,也代表著一份情感的傳遞。 他們分工也很精密,收送的人,跟發放的人如何有默契的交接,讓便當可以快速的到人的手上,不會冷掉。 這些和諧的團體會有一種同步的機制與節奏,就是「同步者的快感」。

團隊中協調技巧:

  • 快速回覆電子信件
  • 分享彼此的奮鬥故事
  • 培養自律的團隊儀式
  • 由每個人都提供一點點的拼圖方式

最後作者也分享一些名言:

以前我相信,時機就是一切。現在我相信,任何事情都有其時機

心得:

「什麼是好時機?」,我們常常在問自己這個問題。 這本書讀到一半的時候,會以為很像是心理學或是生物學的建議書籍。但是隨著書本內容的案例分享與許多有效與睿智的「時間駭客」精髓,作者除了分享時機的重要性之外,更分享了如何在每個時間中,讓事情的效果發揮到最大。 這一本書有實際的建議,也有相當程度的整理與統計,讓你可以更有效地接受相關的概念,相當建議可以看看。

參考文章

[學習心得][Golang] 透過撰寫 Disqus 評論轉移到 Github Issue - disqus-importor-go

$
0
0

前言:

前幾天的文章中 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論,我有提到我將本來部落格中的 Disqus 評論有搬到 https://utteranc.es/的過程,但是在 Disqus 裡面還有接近兩百個留言 (共有 189 個留言,分別在 55 篇文章內) 怎麼辦?

秉持著自己打造自己用的小工具原則( –關在家裡太無聊– ),就寫出了這個小工具來使用,希望能幫助到一些人。 也希望有更多的人一起加入開發相關功能。

TL;DR

本篇文將要介紹以下一些的部分,除了介紹如何使用外。人和

如何導出 Disqus Comment 到 Utteranc

可以參考文章 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論

套件: Disqus to github issues Go

https://github.com/kkdai/disqus-to-github-issues-go

  • 安裝套件方式:``go get github.com/kkdai/disqus-to-github-issues-go`
  • 並且提供一個 CLI 給大家先用,大家可以安裝 go install github.com/kkdai/disqus-to-github-issues-go/cmd/import_disqus_cli

相關指令:

  • -f: Import disqus exported xml file. (get from http://disqus.com/admin/discussions/export/)
  • -u: github user name, you want to use for post github issue.
  • -r: github repo name, you want to use for post github issue.
  • -t: github token, you can request your from https://github.com/settings/tokens.

使用指令範例:

./import_disqus_cli -f="EXPORTED_XML_FILE" -r="BLOG_REPO" -u="GITHUB_USER" -t="YOUR_TOKEN"

包括哪些功能

  • 讀取從 disqus export 的 XML file. (可以參考格式範例在 github )
  • 列出所有的 Comments
  • 列出所有文章(標題,作者,時間)
  • 導入到 github issues (使用 utteranc格式)

接下來會針對幾個部分放上相關程式碼,希望讓大家分享如何寫。

Disqus XML Format 解析

這是簡單版本的 XML Parser,大家可以收到 XML 之後將檔案丟到 XML to Go就可以取得格式。

其中比較需要解釋的如下:

  • Articles: (xml tag: thread) 這邊指的就是原本的文章。他跟留言是一對多的關係。(一篇文章內可以有個留言)
  • Comments: (xml tag: post) 這邊是流言,資料比 Article 還後面需要另外做出 Mapping Table 來鏈結。

ArticleComments連接關係為: Comment.ArticleLink.IDArticle.AttrID

如何作出準備 Import github issue 的資料

目前採取方式是根據在 Githib Issue 的 title 當作 key ,來做 map 。

如果以 path 來當 title , ` mapping := make(map[string] Issue)` 來管理,可以很快速的透過 Map 來尋找到相關的資訊。

留言排序

其中,每一篇文章的留言是需要排序的。為了確保留言可以在年度順序下呈現。需要相關 Sort 的準備如下:

透過準備 Sort Interfaces的方式來讓 []Comment支援 Sort()

Github issue created in Go

關於發送 Github Issue 的部分,使用的是 Google 開源的 golang 套件。 https://github.com/google/go-github,這邊記得要使用最新的版本(筆者時間最新版本是 v35)

import (
   ...
	"github.com/google/go-github/v35/github""golang.org/x/oauth2"
)

相關程式碼如下:

其中 gIssue, _, err = client.Issues.Create(ctx, b.User, b.Repo, input)後會取得建立好的 Github Issue 相關訊息,需要相關的 ID 來後續加入 Comment 。

這一段程式碼,其實對於許多開發者想使用 Github Issue 作為資料管理的方式可以參考(聽說有人拿 Github Issue 來當 DB www) 。

成果

最後執行過後,可以將 Disqus 的留言全部整合進 Github Issue 之中,並且可以保留相關時間。也可以在部落格裡面正常的呈現。希望這個工具能夠幫助大家。

結論:

本文分享了關於 Disqus 的輸出資料格式分析,並且分享了如何在 Github 上面建立 Issue 的相關程式碼。整合起來其實並不難,但是許多時候這些應用往往會變得很有趣。 大家可以參考筆者前一篇文章: [TIL] 為了自己的習慣,弄了一個簡單的服務 Github issue bookmark

相關文章:

[學習心得] LINE Bot 開發者指南 詳解 - 1. 關於 LINE Bot

$
0
0

前言:

各位好, 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines的投影片,考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外,並且特定用這一系列文章加以解釋,希望可以讓更多開發者有更多的了解。 Development guidelines文件內容很多,本篇文章也將以五篇文章的篇幅來加以解釋。

文章索引:

完整投影片鏈結: https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注:

  1. 關於LINE Bot (本篇文章)
  2. 使用Webhook URL接收請求時的注意事項
  3. 發送 API 請求時的注意事項
  4. LINE Login
  5. 其他相關功能

本篇文章將專注在第一個段落,也就是 Page 3 ~ Page 8 的部分。

LINE Developers 相關資源

這邊主要提到兩個網站,分別是:

LINE Bot 的機制

這一張投影片解釋了一個使用者傳訊息給一個官方帳號後,訊息會如何透貴 LINE 的平台傳遞到開發者的(也就是圖上的客戶端)的 Bot 伺服器。 這邊表達了幾件事情:

  • 所有訊息都會透過 LINE 平台的 Talk 伺服器與 Channel Gateway 伺服器處理後傳給 「 Bot 伺服器」。訊息都是透過 Webhook 的方式傳遞,開發者只要依照官方文件開發好像關的 「Bot 伺服器」並且在登入好 webhook 的位置。就可以正確地收到訊息。
  • 開發者處理完訊息後,可以透過 API 的方式發送給 LINE Channel Gateway 。 會在依照相關的訊息發送人透過 Talk 伺服器來發送訊息。

相關的開發者文件可以參考:

關於 LINE Bot 與 Channel 之間的相關性

這張投影片解釋了官方帳號與 Channel 之間的相關性,接下來將為讀者詳細解釋:

此外,這一張投影片也希望帶給各位關於 Provider 的相關概念如下。同一個 Provider 底下的 Channel 拿到的使用者ID會是相同的,也就是 LINE Login 登入取得的使用者 ID 跟 LINE Bot 上面只要是同一個服務提供者(Service Provider) 是相同的。 也提醒 LINE Login 必須要發佈(Publish), 才能被所有人使用。(參考 開發者文件: Published LINE Login Channel ) 。

LINE Bot Glossary

關於 Glossary 部分,這邊講解了許多常被詢問的用字。這邊補充一些大家常用字詞。 大家可以針對這份上面的對照表尋找相關用語。 其實有更多的用字在 https://developers.line.biz/en/glossary/可以找到。

開發 LINE Bot 的開始步驟/發布前的確認事項

這邊分成兩塊,大家可以參考官方文件上的逐步解釋。

這些相關補充事項,希望每一個開發者都能夠遵守。所有的資料也都請以官方網站的資料為準。

結論:

以上就是「LINE Bot 開發指南」第一部分的補充與分享,想要知道更多內容可以查看完整投影片,或是找到其他篇的文章來了解。

想了解更多開發者的活動? 立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev img

[TIL][Golang] 使用 GoReleaser 一次打包多個與多種執行檔

$
0
0

前言:

在二月份文章有提到 使用 GoReleaser 打包你用 Golang 寫的 CLI (Command Line Tool),並且搭配 Github Actions 準備 Changelogs,透過 GoReleaser可以跟 Github Action 整合之外,還可以幫你撰寫 Changelogs 讓版本管控上變得更加的簡單與方便。

但是隨著服務與產品的應用變廣,會有更多的客製化需求發生。那麼該如何讓你的 Github Action 能夠有更多樣的自訂設定呢?

基本需求: GoReleaser with Github Action

大家可以參考前一篇文章,也可以快速學習本篇。

把這個建立成檔案在 .github/workflows/release_build.yml就可以了。 這個其實比較適合 main.go 直接放在 github repo 下的,可以參考 https://github.com/kkdai/go-cli-template的專案形式。

main.go 在子目錄 (sub-folder) Main program in sub-folder

通常在開發一些套件的時候,有時候我們主要 Repository 會是相關的開發套件 (Package) 而會將 CLI 的部分放在 cmd/xxx_cli的資料夾中。需要安裝的時候再跑 go install xxx.com/xxx/uuu/cmd/xxx_cli來安裝。

如果這時候你的 main.go並不在 repo 的主目錄下,而是在 cmd/test_cli的目錄下。 這個時候你就會發生錯誤。

goreleaser error: dones not contain a main function

這時候要如何修改呢?

依照上面顯示,主要修改部分就在於 workdir: ./cmd/test_cli放在 Steps Run GoReleaser 裡面的 with:。 這樣就可以正常的編譯出執行檔案,並且更新 changelogs 。

多個相關的執行檔案需要編譯 / 客製化編譯選項

因為原先在 .github/workflows資料夾中,有相關的指令限制,參考 github action Workflow syntax

如果有想要更多客製化編譯選項如下:

  • 多個資料夾在 /cmd/底下。
  • 讓 GoReleaser 的編譯選項多一些,預設會全部 Compile 。可以挑選只要 Mac + UNIX ,或是加上 x64 選項。
  • 加上一些 enviironment variable (e.g. CGO_ENABLED=0)
  • 打 LDFLAGS 給 go build (e.g. -s -w -X main.build=)
  • 透過 hooks 來跑某一個 compile shell script (e.g. post: ./script.sh )

如果有以上相關的客製化選項,可能就需要將 GoReleaser config 獨立出來成一個檔案,相關做法如下:

主要修改就是透過 args: release -f .goreleaser.yml --rm-dist來將設定透過 .goreleaser.yml來跑。 這樣就等於 goreleaser release -f .goreleaser.yml --rm-dist的意思。

該檔案內容可以參考文件上面的檔案。

也可以參考 PR https://github.com/kkdai/disqus-to-github-issues-go/pull/4

結論與未來

透過引用到 external config file 的方式,來讓 Github Action 的 GoReleaser 可以有更多的客製化選項,其實不僅僅可以只打包,還有更多的方式可以使用 上傳檔案到其他的 Artifactory或是 Docker build。 這樣也可以讓打包產品上,變得更加的簡單方便。

相關文章:

[學習心得] LINE Bot 開發者指南 詳解 - 2. 使用 Webhook URL 接收請求時的注意事項

$
0
0

前言:

各位好, 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines的投影片,考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外,並且特定用這一系列文章加以解釋,希望可以讓更多開發者有更多的了解。 Development guidelines文件內容很多,本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第二篇文章,主要講解的會是關於設定 LINE Bot Webhook 相關注意事項。

文章索引:

完整投影片鏈結: https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注:

  1. 關於LINE Bot
  2. 使用Webhook URL接收請求時的注意事項(本篇文章)
  3. 發送 API 請求時的注意事項
  4. LINE Login
  5. 其他相關功能

本篇文章將專注在第一個段落,也就是 Page 3 ~ Page 8 的部分。

Webhook URL 接受請求時的注意事項

本篇注意事項中,其實在「開發LINE聊天機器人不可不知的十件事」。有許多著墨,這裡稍微帶到與解釋。以下個別根據不同頁面來解釋。

  • A 考量安全性的通訊環境
  • B 接受到請求的時候,回覆狀態代碼 200
  • C 防止來自於 LINE 以外未經授權的請求
  • D 對於大規模訊息處理的考量

A 考量安全性的通訊環境

這部分提醒大家需要提升 Webhook 伺服器的安全環境,這邊也提醒大家根據 2021/01 的新聞 ([Updated] TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021),如果要能正常地接受到 LINE 平台的 Webhook 必須要讓伺服器支援到 TLS 1.3 。

更多訊息歡迎參考以下文章:

B 接受到請求的時候,回覆狀態代碼 200

在 「開發LINE聊天機器人不可不知的十件事」的文章的(第三件事:盡快回覆LINE平台正確的HTTP狀態碼). 中,也有提到 LINE平台在傳送事件訊息到開發者Webhook伺服器之後,若是等待1秒鐘沒有得到任何HTTP狀態碼的回覆,就會發生逾時(Timeout)錯誤,LINE平台會關閉該次HTTP連線並認為該次傳送結果失敗;若是一直發生傳送失敗的狀況,LINE平台可能會將該Webhook伺服器封鎖或進行其他處置,造成開發者的應用服務無法正常運作。 請開發者們要注意到相關的事項。

更多訊息歡迎參考以下文章:

C 防止來自於 LINE 以外未經授權的請求

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第二件事:驗證訊息來源)也有提到,當開發者的Webhook伺服器收到以POST方式所傳送的LINE事件訊息時,必須要立即驗證該事件訊息是否真的來自LINE平台,以避免被偽造的訊息所欺騙造成資訊安全危機。標準的驗證方式是檢查所收到HTTP請求標頭(HTTP request header)中的數位簽章。如果該HTTP POST訊息是來自LINE平台,在HTTP請求標頭中一定會包括X-Line-Signature項目,該項目的內容值是即為數位簽章。

更多訊息歡迎參考以下文章:

D 對於大規模訊息處理的考量

這邊有分享一些給開發者的經驗分享,根據業務的發展狀況下,以下幾個時間將會有大量的訊息灌入開發者們的 LINE Bot ,希望開發者們可能要注意到。 (訊息集中的部分)

針對這些大量的訊息可能湧入下,建議開發者們必須要有相關的備案需求。避免因為訊息過多而造成開發者的伺服器不堪負荷。 建議如下:

  • 是否有水平擴張的機制來面對大量的需求。 (Auto-scaling)
  • 建議檢查每一次訊息來之後的回覆時間,儘量採取非同步方式。盡可能先回覆之後,在另外發訊息給使用者。如此一來可以避免卡住太多訊息。

此外,本頁投影片也告知幾個重要消息:

  • 請勿對 GW 伺服器進行壓力測試,如果開發流程需要做壓力測試請透過其他方式來進行。 參考 Development guidelines

E-1 Webhook 的 ON/OFF

這邊提到的是切換 Webhook 開關跟「自動回覆訊息」還有「加入好友的歡迎訊息」的解釋。 這邊主要提醒開發者們,如果忘記將「自動回覆訊息」關閉的話,即便你開起來 Webhook 的開關,雖然可以收到,還是會透過「自動回覆訊息」來回覆。 相關的細節在下一頁會有更多解釋:

相關資料:

E-2 Webhook 的 ON/OFF 選項設定(跟「自動回覆訊息」還有「自動歡迎訊息」的互動)

  • 使用「Webhook],使用自動回覆與加入好友歡迎訊息:

    • 訊息來了,同時會送到 Webhook 與自動回覆。
    • 但是因為自動回覆會先回覆,Webhook 不需要再回覆即可。
  • 使用「Webhook],不使用自動回覆與加入好友歡迎訊息:

    • 建議開發者使用這個方式,完全透過 Webhook 來收取訊息與發送訊息。
  • 不使用「Webhook],使用自動回覆與加入好友歡迎訊息:

    • 這樣 Webhook 將不會收到訊息,完全透過自動回覆來回覆。
  • 不使用「Webhook],不使用自動回覆與加入好友歡迎訊息:

    • 如同投影片介紹,目前不開放也不建議開發者這樣設定。

F 其他注意事項

F-1. 一個請求包含多格訊息格式

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第四件事:LINE平台所傳送的事件是一個陣列) 有更多清楚解釋,歡迎大家去了解一下。 因為 Messaging API 帳號沒有大量的事件訊息傳入,每次所收到事件幾乎都只有一筆資料,所以開發者會誤以為每個事件訊息只需要處理一筆資料。事實上,LINE平台傳送給Webhook伺服器的HTTP請求本體是包括一個或多個Webhook事件物件的JSON格式物件

F-2. Webhook 新增屬性的對應方式

這邊有建議開發者們,對於屬性的判斷上儘量要當成獨立個體之外,對於可能的新增屬性建議也要有比較好的處理方式。 建議方式可以透過 switch case 的方式來判斷,僅僅對於有處理的事件(event) 來處理,其他都略過。

相關文件:

F-3. 關於請求標題中的驗證

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第二件事:驗證訊息來源) 有更多清楚解釋。文章中建議驗證方式如下:

  1. 以Channel secret作為密鑰(Secret key),使用HMAC-SHA256演算法取得HTTP請求本體(HTTP request body)的文摘值(Digest value)。
  2. 將上述文摘值以Base64編碼,比對編碼後的內容與X-Line-Signature項目內容值是否相同;若是相同,表示該事件訊息是來自LINE平台,否則拒絕處理該事件訊息。

相關文件:

G 建議的請求處理步驟

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第三件事:盡快回覆LINE平台正確的HTTP狀態碼) ,在此僅列出相關流程圖,更多內容歡迎各位去部落格查看。

H. GW 伺服器 -> BOT 伺服器的通訊錯誤

H-1. 關於 Error Notification

這部分可以參考以下的流程圖:

這邊是敘述說如果 LINE 平台有問題發生的時候(或是無法正確收到開發者的回覆時),將會另行發信給開發者的信箱中。相關的信件內中如文件上。

參考以下文章:

結論:

以上就是「LINE Bot 開發指南」第二部分的補充與分享,想要知道更多內容可以查看完整投影片,或是找到其他篇的文章來了解。

想了解更多開發者的活動? 立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev img

[資源分享] 關於線上書籍的相關免費資源(圖書館免費線上資源)

$
0
0

有在看我部落個的朋友,知道我經常在閱讀書籍(因為實體書太佔空間,目前以電子書為主),並且貼在「書海漫遊」項目中。 之前才聽到同事分享資訊,原來有更多免費資源可以使用,相關使用方式如下:

免費正版電子書? 來跟圖書館借吧

其實有圖書館都有免費的電子書可以借,各位可以來相關網站去借。 而且那些圖書館又可以線上辦證,不必一定要是該縣市居民,等於只要在家辦辦帳號,就可以享有這些免費資源。這些圖書館包括了 國立臺灣圖書館 / 台北市立圖書館 / 新北市立圖書館 / 台中市立圖書館 等等。裡面其實有更種書籍,但是個人推薦可以借電子雜誌,因為台北好讀的 App 目前只支援 iPad /iPhone /Mobile 還有客製化的閱讀器,必較建議使用 iPad 來看雜誌的版面。 詳細網站可以去台北市立圖書館 x 台北好讀

優點:

  • 如果有台北市立圖書館,可以一個月可以免費借幾本。
  • 蠻推薦雜誌,因為可以用 iPad 來看。版面比較固定。(反正其他平台也都是 PDF ,還要錢)

要去哪個圖書館找電子書?線上來找找

可以再搭配這個圖書館書籍搜尋網站使用:

台灣圖書館電子書搜尋

想買的書哪裡找的到電子書?

電子書是要用買的話,可以在這個網站一次找大部分的書城: https://taiwan-ebook-lover.github.io/

台北市立圖書館疫情加碼

愛看書的市民朋友,考完會考需要放鬆腦袋的青年才俊,活到老學到的樂齡讀者,還有喜歡繪本讀圖像書的大小朋友,現在就登入您的帳號密碼,盡情悠遊書中世界吧!

提醒您,閱讀量力而為,不要一口氣借太多讀不完,反而浪費點數喔!讓我們學會分享,用愛閱讀吧!

傳送門:

https://tpml.ebook.hyread.com.tw/index.jsp

除了Ebook Taipei,本館還有很多電子書資源,請點以下連結,都去看看吧:

https://reurl.cc/g8985N

首次操作看這邊,跟著做一點都不難:

https://www.facebook.com/154691774541075/videos/1401090570099383

圖書館也能借免費線上影片

這邊順便整理一下,要借線上免費影片,也可以在圖書館借。(圖書館真棒!!)

公共圖書館區域資源中心電影院 – 免費提供數百部電影、紀錄片等讓你線上看

參考文章


[好書分享] 岩田聰如是說:從天才程式設計師到遊戲公司社長,任天堂中興之主傳奇的一生

$
0
0
岩田聰如是說:從天才程式設計師到遊戲公司社長,任天堂中興之主傳奇的一生。

作者: ほぼ日刊イトイ新聞  出版社:台灣東販 
語言:繁體中文 ISBN: 9789865119263 eISBN: 9786263046443 字數: 51,266

買書推薦網址:

前言:

這一本是今年所讀完的第七本書。42 歲接下任天堂社長,領導著任天堂打造出 NDS, Wii 顛覆遊戲界的岩田聰社長,但是卻英年早逝。這本書不是要分享他成就或是相關豐功偉業,而是分享他在日常生活跟同事們的聊天的想法,也讓大家知道他是始終如一的人。

有點像是末代武士裡面的橋段:

Emperor Meiji: “Tell me how he died.” Algren: “I will tell you how he lived.”

相當推薦大家來看這本,短短的一本書但是會讓你再三回味的。

內容簡介與心得:

約莫二十年前,山內溥安排岩田聰進入任天堂本社,擔任經營企畫室長,並且在兩年後自己退休時指定岩田先生接下任天堂社長職位。當時任天堂可說是正值風雨飄搖之際,儘管財務情況一直很健全,但N64和NGC兩台家用主機接連失利,市占率甚至被夾帶雄厚資金進入市場的新挑戰者,也就是微軟推出的 Xbox 主機所追趕。
 
當年年僅四十二歲的岩田先生,接下此一重責大任後便不負所托,打出「擴大玩家人口」的大旗,先後推出掌上型主機「Nintendo DS」以及家用主機「Wii」,以和過去主機不同的異質變化,吸引玩家、曾經是玩家和不是玩家的人,成功帶領任天堂走出低潮,並且創下公司成立以來最高營收。可說是名符其實的「任天堂中興之主」。

 
本書是從《HOBO日刊ITOI新聞(ほぼ日刊イトイ新聞)》網站所刊登的岩田聰訪談中,擷取岩田先生說過的話,重新編纂而成。另有部分言論節錄自任天堂網站上的「社長提問」專欄。
 
岩田先生是一位在媒體面前談話時,幾乎從不把自己當作話題主角的人。若是為了公司和專案,基於「由我出面是最合理的判斷的話」,他會回應遞到眼前的麥克風,可是言談之中僅將自己的事擺在次要。
 
不過,就如多數人所知道的,岩田先生是一位誠實無偽、一路走來始終如一的人。
 
他曾經代表公司或開發商立場,於各種場合發表言論,將這些言論集結一看,就彷彿多個圓圈的交會處,疊合出另一種顏色般,自然而然地浮現出「岩田先生本人的話」。

章節條列

第一章 岩田先生成為社長以前。

這一章節內容來自於岩田先生的採訪內容,可以感受得到岩田先生對於遊戲製作與工作有著無比的熱情。並且也在 HAL 研究所任職時間,因為遭遇了公司的 15 億日圓債務影響,當時才 33 歲的岩田先生,也在當時培養經營公司的能力。 這邊快速歸納一些我覺得很難得的特質:

  • 儘量抽出時間跟全公司的人 1 on 1
    • 因為走馬上任,透過跟全公司的人面談了解大家的想法與公司的問題。更了解該怎麼做,這習慣也儘量延續下去。
  • 抱持著幫大家解決問題的想法來傾聽(不表達意見)
  • 經常問人:「你覺得快樂嘛?」「你覺得這個有趣嘛?」讓遊戲回歸本質。
  • 遇見各種客戶的問題,絕對不逃避。並且主動起來面對客戶,面對問題。「逃避的話,我會後悔一輩子」的想法來面對事情。

第二章 岩田先生的領導能力。

這邊有一些岩田先生的領導力的表現,相當適合想轉職管理階層的人或是轉換到專案管理階層的人來看。

  • 找到瓶頸所在:不要一頭鑽進問題,看清楚問題的面貌相當的重要。
  • 只有自己才能解決: 要挑對的的問題來面對,讓團隊的其他人替你解決其他問題。
  • 任天堂的最終極目標就是「給人驚喜的感覺」
  • 專案進行最順利的狀況是:「當發生了不在原本沒預期的事情,但是有人主動願意主動跳出來願意接手處理,解決問題。」
  • 讓團隊中的每個人,對於產品有著共同的願景。才能有共同的想法一起努力。
  • 對每個同仁都抱持著敬意,每一個同仁一定有自己最專長的所在才會被錄用。 要能夠善用不同的人。
  • 「絕對不要有如果有三個自己,那該有多好的愚蠢想法」。

關於面試,這邊也有許多很有見地的想法:

  • 不要問面試者難以回答的問題,反而要問面試者可以侃侃而談的問題。透過大量的對談,來了解對方是不是能來幫助你的人。
  • 要挑選可以放心責怪「笨那!」的後選者,那樣的人才能有膽是能面對困難的情境。並且能夠輕鬆的討論彼此缺點的人,往往在合作上更不會有綁手綁腳的害怕感。 想做就去做,想質疑就要質疑。

此外,我也覺得岩田聰先生本身也相當有傳教士的精神。他很喜歡鼓勵每一個同事,主動去發掘每一個同仁特色的一面。

「一個人聽懂一件事情,跟他能不能夠把這件事情講給其他人聽,是完全不同的兩件事」。(這句名言,我覺得超棒)

第三章 岩田先生的個性。

這一個章節列出許多岩田聰先生相當可貴的個性:

  • 是個打破砂鍋問到底,熱愛學習的人:
    • 了解道理是一件事,要能讓對方心平氣和接受又是另外一門學問。
  • 發現反饋的能力:
    • 如同遊戲一樣,給予同仁反饋與建議,讓每一個同仁不斷的進步。
  • 寫程式經驗拿來經營公司:
    • 就像發現 bug 一樣,一開始都不會認為是自己問題。需要詳細的思考對方的問題與自己的問題,再來思考是不是有一個良好的方式可以彼此有更良性的溝通。
  • 只要是合理的事,要提早下定決心(貫徹到底):
    • 這邊是指岩田聰先生出來代表任天的發表遊戲的事情,為此他努力學習英文,認真表達出公司的面向與遊戲本質。
  • 「程式設計師不可以說 No」
    • 這邊指的是,程式設計師不要一開始就自我設限,讓許多的好想法或是(比較難開發)的想法被扼殺在一半。
  • 透過「當事人不會後悔」的方式來排定事情先後順序
    • 這樣一來不僅不會浪費時間,更可以讓每一個人(事)(物)都被妥善的對待。

名品小句子:

「客人在吃餐點的時候,很多時候說太多了,可能是因為不好吃。 不是因為吃不下,這時候老闆可能單純的給予比較少的食物,並不會真正的解決問題。」

第四章 岩田先生信賴的人。

這一個章節主要分享著岩田聰先生所信賴的人們的事情。

  • 宮本茂先生經常可以透過一個想法來解決複數個問題。

  • 宮本茂經常會抓著公司內同事,請他來試玩他的遊戲,藉以獲得回饋。(也可能是宮本茂先生喜歡面對玩家純真的一面)

  • 對於電腦本質了解透徹的宮本茂先生,這邊是指宮本茂先生的底子深刻。

  • 解決遊戲的兩個做法,一個是重做,一個是小改。系井先生為了好玩會堅持把遊戲打掉重做。

  • 宮本茂先生經常會砍掉重做,但是可能是遊戲引擎跟玩法改掉,但是可以重複利用的部分還是會儘量思考如何利用。

  • 前社長山內博的教誨:「不要一直走老路,要勇敢走新的道路」。

  • 所謂的天才可能是「把其他人討厭而無法做完的事情,持之以恆地做完」

第五章 岩田先生所追求的遊戲。

這邊開始介紹岩田聰先生打造主機跟遊戲的一些想法:

  • 打造心目中的遊戲主機:希望可以打造出回到家馬上會想要打開的電玩遊戲主機。
  • 打造出遊玩架構:有一個時期,任天堂的主要目的是打開遊戲族群的人口,所以他們會將由玩遊戲的方式從手把到遙控器。透過體感的方式來吸引更多的遊戲人口。這也是Wii 的誕生原因。
  • 透過突發奇想的討論,或許不是浪費時間: 曾經有段時間岩田聰先生希望可以讓小孩子遊戲時間不要太長,但是這樣得想法明顯的跟公司的收益相違背,透過不斷的討論,誕生了遊戲中的遊玩時數系統。也可以讓家長跟小孩能夠溝通,彼此約束。
  • 沿著過期成功的路,是最恐怖的:有一個時期,任天堂不斷的創造出新的主機系統。從 NDS 到 3DS 到 Wii ,他們認為走著過去成功的路,往往才是最容易失敗的。
  • 任天堂大亂鬥是慢慢生長出來的遊戲: 一開始只是希望能做出任何人都能上手的格鬥遊戲,後來隨著許多角色的加入,並且有更多的想法加入,才能變等現在有趣的模樣。
  • 壞莉歐的誕生是為了顛覆任天堂:壞莉歐一開始誕生的想法是要做瑪莉歐本來做不到的事情:壞事,小遊戲,或是一些其他的遊戲類型。這種「旁系」的遊戲類型,反而引吸到另外一群遊戲族群呢!
  • 輕度玩家與重度玩家:大部分時候,任天堂會以吸引更多玩家加入的方式來讓輕度玩家來加入。但是也會有給重度玩家的遊戲類型。

名品小句子:

為什麼這塊小石頭要放這裡? 如果設計者講「不為什麼」,這是相當危險而且要不得的。
一開始做遊戲會想加入所有元素,但是後要完成的時候往往是在慢慢的減法中妥協與完成。約束是創造之母阿!

第六章 別人眼中的岩田先生

這邊有列出許多任天堂內部神級人物眼終的岩田聰先生,透過這個方式也呼應到前面許多形容岩田聰先生的特性。

  • 宮本茂先生眼中的岩田聰先生:
    • 不像是上司,反而像是朋友。
    • 喜歡透過命名方式來凝聚共識。比如說產品命名,或是遊戲使用共同名稱。 (Wii Sport, Wii Fit …)
  • 系井先生眼中的岩田聰先生:
    • 讓人覺得信賴,但是不敢懈怠的同事。

第七章 岩田先生這個人。

最後則是透過許多短句子,來幫岩田聰先生結尾。

「跟別人共事的時候,一定要讓人覺得下次一定要繼續跟我一起做事的想法」
名片上我是社長
腦海中我是遊戲開發者
在心中,我是一名遊戲玩家

心得:

可能是因為是日本人寫的書,連寫章節摘要的時候,都會打上許多的「先生」這樣的詞(笑)。 這一本書並不算長,算是透過採訪搜集文章的一種。還有加入許多人的側面採訪的方式來了解這個令人敬佩的人。雖然岩田聰先生相當年輕就當上社長,但是相當的謙虛與願意解決許多問題的態度,是相當令人相賞的。這不是一本很厚的書,但是我應該會經常不斷的拿回來翻著看,因為有許多簡短的文字,卻是如此的精簡而有力,讓我會不斷的思考。

[學習心得] LINE Bot 開發者指南 詳解 - 3. 發送 API 請求時的注意事項

$
0
0

前言:

各位好, 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines的投影片,考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外,並且特定用這一系列文章加以解釋,希望可以讓更多開發者有更多的了解。 Development guidelines文件內容很多,本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第三篇文章,主要講解的會是關於發送 API 請求的時候需要注意的事項。

文章索引:

完整投影片鏈結: https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注:

  1. 關於LINE Bot
  2. 使用Webhook URL接收請求時的注意事項
  3. 發送 API 請求時的注意事項(本篇文章)
  4. LINE Login
  5. 其他相關功能

本篇文章將專注在第一個段落,也就是 Page 20 ~ Page 30 的部分。

發送 API 請求時的注意事項

本篇注意事項中,將會帶出以下的相關項目。

  • A. Channel Access Token 的發行

  • B. Channel Access Token 自動更新
  • C. Channel Access Token 有效上限數量
  • D. 訊息發送完成後接收回應
  • E. API 請求重試
  • F. 請求的相關限制
  • G. 回應 ( reply ) 訊息與推播( push )訊息
  • H. HTTPS 內容的使用

以下開始將會逐一針對每一個頁面詳細解釋:

A. Channel Access Token 的發行

Channel Access Token 是整個 Channel 最重要的憑證,透過該憑證可以有許多權限可以修改該 LINE Bot 的設定。所以在授權上要務必小心。 這邊也提供一些小訣竅:

  • 建議不要使用沒有時效性的 Channel Access Token ,建議使用 API 來要求。
  • 使用 API 來申請 Channel Access Token 建議使用 v2.1 的方式來發出需求。

如此一來除了可以確保整個頻道(channel) 憑證的安全性,必要時也可以將有暴露考量的 token 撤銷掉。

參考文章:

B. Channel Access Token 自動更新

接續前一頁,針對 Channel Access Token 的管理上。建議使用短期有效的 Channel Access Token ,並且在期限即將到期的時候, Issue 新的 Token。 請注意 Access Token 個數有上限(下一頁解釋),所以超過個數時需要將多的撤銷 (Revoke) 掉。

C. Channel Access Token 有效上限數量

這一篇有詳細敘述關於 Channel Access Token 的個數:

  • Short-lived channel access token (短期) :
    • 申請方式: 透過 API ,參考說明文件
    • 個數: 30 個
    • 期限: 30 天
  • Long-lived channel access token (長期):
    • 申請方式: LINE Developer Console
    • 個數: 1 個
    • 期限: 直到重新申請為止。

相關文件:

D. 訊息發送完成後接收回應

這一頁投影片是敘述,如果開發者使用 Send push message或是 Send reply message的系統伺服器的回應狀況。通常成功的話,就不會回覆任何資訊(empty json ) ,如果有誤才會回覆詳細的錯誤資訊。

相關文件:

E. API 請求重試

有些時候發送大量的 API 呼叫的時候,因為有一些不可預期的狀況,造成 API 呼叫無法成功,或是無法收到回應的狀況。這時候為了能夠確認前一次的呼叫是否有成功,平台這邊有設計相關的重試 (Retry) 機制可以檢查。

透過 “Safely retrying” 機制。 可以讓開發者測試一下上次的訊息是否有正確的發送成功,並且也可以確保有無任何的使用者被漏發了。 相關的使用情境如下:

  • 上次不知道有無法送完成,呼叫 “Safely retrying” 可以重複發送同一則訊息。 有收過得不會收到重複訊息,沒收到的可以確保收到。
  • 上次發送發生了平台無法完成指令的意外,透過 “Safely retrying” 可以跟平台確認上次的狀況。 如果上次有完整發送完畢,也不會有重複計費的疑慮。

相關文件

F. 請求的相關限制

開發者在使用 API 的時候應該要避免大量的呼叫 API 超過設定的 Rate Limit 而造成系統判斷為惡意的呼叫。 其中 Rate Limits可以參考以下相關訊息:

如果超過了這些次數的限制,則會獲得 420 Too Many Requests的回應。請開發者們一定要注意。

相關文章:

G. 回應 ( reply ) 訊息與推播( push )訊息

這邊則是詳細敘述關於 Reply Message 跟 Push Message 的差別:

  • Reply Token 有時效性。更多資訊可以參考 「開發LINE聊天機器人不可不知的十件事」 裡面的相關註解。
  • LINE Messaging API的Webhook的下列事件物件會帶有Reply token:message、follow、join、postback與beacon。使用Reply token傳送訊息請注意以下二點:
    • Reply token的有效期間非常短,在收到Webhook事件後必須盡快使用。有效期間會隨著系統狀況而調整,所以我們也不便對外提供精確的數字。可以確定的是這個數字會以秒為單位,開發者是無法以Reply token回覆需要經過數分鐘以上處理時間才能獲得結果的訊息。這個目的是希望開發者能夠在最短的時間內回覆用戶的訊息,提供更好的使用者體驗。
    • Reply token僅可以使用一次,如果有需要在收到Webhook事件後分多次回覆,就必須使用Push message的方式來傳送訊息。

相關文件:

H. HTTPS 內容的使用

如果在訊息內需要加上圖片,影片,音訊等等相關資料。記得除了需要符合 HTTPS 的安全規範外,還需要符合 TLS 1.2 以上的安全規範,不然將無法正確顯示。 將不在支援 TLS 1.0 與 1.1 (參考 Updated: TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021)

相關文件:

結論:

以上就是「LINE Bot 開發指南」第三部分的補充與分享,想要知道更多內容可以查看完整投影片,或是找到其他篇的文章來了解。

想了解更多開發者的活動? 立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev img

[好書分享] 40歲,精采人生才開始: 從1萬人的經驗談看見真正該做的事

$
0
0
40歲,精采人生才開始: 從1萬人的經驗談看見真正該做的事
できる40代は、「これ」しかやらない : 一万人の体験談から見えてきた「正しい頑張り方」

作者: 大塚壽  譯者: 沈俊傑  出版社:先覺出版 
出版日期:2021/05/01 
語言:繁體中文 ISBN: 9789861343815 

買書推薦網址:

前言:

這一本是今年所讀完的第七本書。 這一本當初在書店決定要翻閱它的時候,真的只是因為他的書名。(好像買書就會洩漏自己年紀一 樣),不過其實這一本書的內容相當的實用。相信許多上班族會希望他們在三十多歲就能夠知道的事情。當初一翻到這本書,就是談到裡面關於 work-life balance 相關的章節,想不到裡面有許多相當有用的建議與體認。身為業務人的作者更了解人到了四五十歲經常有的迷惘與困惑。

蠻推薦大家去看這一本書,就算你還沒 40 啦,哈哈!

內容簡介與心得:

你還好嗎?「40歲」後悔度調查
□ 每天都很忙碌,但並不討厭忙著工作的自己。
□ 工作還是實務至上,重點是親自動手。
□ 雖然知道事情要交辦出去,但到頭來還是忍不住自己攬下來。
□ 平日經常加班,但假日時間都拿來陪伴家人。
□ 雖然不排斥升官發財,但盡量不去想這些事情。
□ 最近的年輕人不喜歡別人過度干涉,所以盡可能跟對方保持距離。
□ 大學畢業至今還沒換過公司。
□ 現在完全沒時間留給興趣,覺得退休之後再培養就好。
勾選超過5項,可能就是「愈拚命努力,愈容易感到後悔」的飲恨者!
請立即改變想法吧!

章節條列

chapter 1 〔生涯篇〕四十歲是決定「下半生怎麼活」的最後機會

40 歲經常伴隨而來的就是資深與經驗,一家公司也往往工作了十多年了。 這個時候作者提供了一個表格,可以讓讀者們去思考是否公司有相關危機的「自我現況分析表」。 裡面大約有了以下幾個項目:

  • 公司所在業界優勢
  • 公司自評:公司在業界的評比。
  • 部門所在公司比例中的評比。
  • 直屬上司的評比。
  • 自己目前擁有技能的評比。

這些評比可以幫助讀者對於目前的現況有一個概略性的了解,如果真的所在的狀況不太樂觀的話。也應該趁四十多歲的狀況,儘早作出相關的改變,一切都還來得急喔。

裡面也提到了,建議每一個人透過透過「金錢」來幫自己目前的現況評價,作為一個相對於客觀的狀況分析。 同時也希望透過現況分析,讓讀者更能夠了解,哪一些技能是應該要開始培養的,並且作者也建議應該要培養個人品牌與可以賺錢的副業(這邊指的可以賺錢,大概是要有月收入 7000 日幣)。

chapter 2 〔公司篇〕身處「暗潮洶湧的組織」需培養出高超的泳技

第二章提到的就是 40 歲了之後,對於工作也應該有了一定的想法。這邊也有一些蠻值得思考的話語:

  • 提早思考是否要升官,透過時間分配對自己的工作生活負責。
  • 培養組織相關技能,捨繼個人技能。這邊指的是充實個人人脈,努力跟人合作。
  • 與其討好上司,不如跟下屬打好交道。

其中跟下屬打好交道這個思維算是蠻有趣的。因為 40 歲大多都是小主管,透過跟下屬打好關係,才能夠讓組織的績效夠好,才能夠被上司真正的賞識。反之,如果一昧的討好上司。卻不斷的壓榨下屬,到時候下屬擺爛自己的成就還是無法被看見。

chapter 3 〔管理篇〕掌握「正確的交代方式」,自己和團隊才動得起來

這邊分享的是身為管理階層,在 40 歲的時候應該要具有的能力:

  • 掌握「交辦大原則」: 學習如何有效地交辦事項。
  • 不要經常抱怨,卻不去解決問題。
  • 要懂的如何請求比自己年長的下屬
  • 刻意安排「管理時間」:這邊許多的書籍也有提到,必須要安排 1 on 1 的時間
  • 夾心餅乾的人才是自我價值的呈現: 避免 Garbage in Garbage Out

這邊很重要的就是要認清自己在管理上的價值,也必須要讓自己更相信團隊。更信任下屬才是。

chapter 4 〔私人篇〕暫時拋開工作,完全投入「個人生活」

這一本書的作者是日本人,在日本裡面 40 歲就是標準的「燃燒生命為公司付出的年紀」。但是作者要求每一位讀者應該要提早去思考,要如何「增加個人的生活」。

  • 沒有少了你會不行的公司,只有你少了公司會沒有生活目標的人生。
  • 需要儘早培養「自己理想生活的人生」,不然退休後往往會喪失生活目標。
  • 需要更早的注重家庭生活,因為四十歲往往就是容易跟家人,跟小孩喪失聯繫的一個十年。也是很容易造成中年離婚的原因。
  • 週末時間試著要拆開成六等分,除了要有自已的時間外。一定要保留時間給家人跟朋友。
  • 一定要將自己的時間適當的分給小孩,吃一頓飯是很重要的。(現在都 WFH 每天我都跟小孩吃飯 ~笑)
  • 眼裡只有工作的人,真的是相當的可憐。並且工作外,自己有無相關的興趣?
  • 最後一個項目就是要健身,一定要透過肉體「實際的對抗老化」。

最後作者也分享了一個案例,透過自己對於生活的要求。對於音響的喜愛後來變成自己退休後的副業,生活也相當的愉快。

chapter 5 〔時間管理篇〕工作效率好的人都會「這麼做」

四十多歲的人,大多已經在自己的工作步調上工作了十多年(可能會更久)。這時候許多的人沒有去好好地審視自己的工作效率,這邊提供一些讓讀者可以好好檢查自己的方法。

  • 不要試著什麼事都掌握,只做重要的事情。(沒有人能取代的事
  • 將自己十分鐘抽出來,做一些平常不常做的工作。搞不好能發現某些能增加工作效率的方式。
  • 追求專心做事的時間(番茄時鐘?)(連續工作時間)
  • 遵守時間表,如果沒辦法做完,試著放到一半(不要做一個段落)。很多書上有這樣教,這樣一來往往能讓你心中掛念,然後之後會想出更好的做法。
  • 「重要但是不緊急的事」往往要更認真的思考,更認真的做。避免變成「重要又緊急」。

試著將以往不在意的事情去做,往往會給你更多的體現。

chapter 6 〔人脈篇〕四十歲後,「往來對象」會決定人生成敗

對於一般人來說,人脈最高峰就是在學生時期。 20 ~ 30 多的時間,因為換學校,換工作會認識很多人。但是到了四十歲之後,往往就會越來越懶得跟人聯絡,這個時候的人脈往往更佳的珍貴。

  • 透過聚會方式,多多認識不同的人。 (不喜歡喝酒,可以讀書會。
  • 另外一本書也有提過,大概十多個人的聚會,讓彼此認識的人脈。往往可以讓彼此達到最高的效益,往往生意就是這樣來。
  • 虛心向任何人請教,並且也要認識非同溫層的人。
世界上有兩個東西不會出現,一個是幽靈,一個是下次。

你永遠不知道是下次先來,還是死亡先來。到了四十歲後,往往會開始有朋友離開所造成的遺憾,千萬不要讓自己有類似的遺憾。

透過週期性聚會,可以約來業務相關的人,也可以把之前的窗口一起找來。人數大概是十個為上限,這樣一來可以讓彼此都熟識,也可以擴展彼此的人脈。許多的書籍與課程都有提到相關的事情,也都認為這個方式所形成的人脈是有用且有效的。
  • 個人好店與私房景點是相當重要的:這個是我現在比較沒有思考的,雖然說是因為作者是業務。但是我認為就算是工程背景也應該要能夠有私房好店。

chapter 7 〔學習篇〕在有限時間內,獲取最大成果的「大人學習法」

這是一本相當新的書(2020 年底出的),所以這一個章節討論的就是「疫情狀況下,需要有的新能力」。

  • 遠距辦公的溝通能力:有效的溝通與交辦事項能力,有效地掌握遠距會議。
  • 書寫能力很重要,往往會書寫的人「獨立思考的能力也很強」。
  • 集中學習可以變現的能力,要多多學習相關可以賺錢的能力。如果要有證照,應該在於證照所帶來的學習能力而非證照本身。
  • 閱讀新的書籍與幾本經典書籍可以讓知識學習起來更有效率。
  • 培養「說得出來的素養」,透過上知天文天文下知地理的常識,可以讓溝通更有趣。也可以讓自己的人脈更好,並且讓自己的價值更高。

心得:

這一本書雖然是日本作者寫的,但是放到台灣其實很適合給三十五歲以上的人來看。也希望每一個讀到這一篇的讀者,可以去看看這本書,培養自己的能力之外,也培養出許多屬於自己的人脈。

[好書分享] 什麼才是經營最難的事 - 矽谷創投天王告訴你真實的管理智慧

$
0
0
什麼才是經營最難的事 - 矽谷創投天王告訴你真實的管理智慧
The Hard Thing About Hard Things : Building a Business When There Are No Easy Answer
原文作者: Ben Horowitz  
譯者: 連育德  
出版社:天下文化 
出版日期:2018/10/24

買書推薦網址:

前言:

這一本是今年所讀完的第八本書。 作者 Ben HorowitzP 是安霍創投(Andreessen Horowitz)(俗稱 a16z) 創始人之一,也知名的創業家。並且有自己的媒體平台外,也是多本書的作者, 而這本書就是分享作者 HorowitzP 身為執行長的過程之一。裡面有提到相當多創業執行者每天為了金錢睡不著的日子,並且為了裁員(作者來歷經數次)後,如何讓企業能夠起死回生的過程的心力過程都寫進去了。 這一本書你不會看到光鮮的執行長過程,反而是每天睡不著,每天自我懷疑,每天被董事會質疑,被投資人挑戰的過程。 相當寫實啊!

並且裡面有許多挑選優秀銷售經理的方式,裁員的溝通過程,如何做好 1 on 1 的溝通方式,如何能夠做出身為執行長的困難決定。這些過程我認為都是許多制式化書籍所不會提到的,如果你也想要了解這些過程。也來看這本書吧!

前面三個章節敘述著作者如何經營雲端公司 Loudcloud ,上市後順利賣給 EDS 並且將其中雲端操作系統讀另成新公司 Opsware ,最後將 Opsware 經營成業界第一並且賣給 HP的故事。 後面則是講解身為執行長的許多細節。

內容簡介與心得:

本書猶如商場上的鬥陣俱樂部,當許多人揚言創業有多簡單時,只有矽谷知名企業家霍羅維茲敢直言:「創業是多麼艱難的一條路!」並揭開成功企業主不敢說卻偷偷做的經營學問面紗!

霍羅維茲是安霍創投(Andreessen Horowitz)的共同創辦人,同時也是矽谷最受尊敬且經驗豐富的企業家,在本書中他以其自身經歷,講述包括如何創業、營運、銷售、採購、管理、招募優秀人才、解雇員工和投資等商學院沒有教的實用智慧,以及如何解決商場上最棘手的問題。他的部落格(bhorowitz.com)有近千萬名粉絲追隨、仰賴他給與企業管理的建議,包括如何解雇你的好友、從競爭對手挖角、選對正確時機賣掉公司,以及如何培養及維持一個執行長該有的心態。

多年來,霍羅維茲從引領雲端潮流創辦響雲端,到成立大受好評的安霍創投,發跡過程布滿荊棘,每個挑戰都淬鍊成他在書中的獨到見解。本書不吹噓個人成就,只是就事論事,逐一分析遇到難題時該如何解決。這些重大挑戰包括:

‧怎樣幫公司找對人才?
‧營運重擔壓在肩上,如何戰勝心魔?
‧你是正面思考還是正面妄想?
‧如何將好友降職?
‧身為領導者是否應該實話實說?
‧聰明員工反成老鼠屎,怎麼辦?
‧是否該有職銜與升遷制度?又該如何管理?
‧從朋友的公司挖角,OK嗎?
‧是否該賣掉公司?又該如何辨認正確時機?
.執行長最難學的一門課到底是什麼?

章節條列

第1章 共黨爺爺創投孫

這個章節是作者的自我敘述,從資工研究所畢業後,加入了新創公司過著辛苦的日字。後來辭職後到了大公司 Lotus 工作後,但是後來卻又因為看到了 Mosaic (第一代的瀏覽器) 產品後,被網際網路的發展性所震攝到。抓住了一次的機會,加入了當時剛發展的 Nescape 。 並且也遇到他的好友 (Marc Andreessen )。 作者接著分享他們在 Nescape 的過程,從獨霸一方並且是矽谷的佼佼者。到被微軟的打到沒落的過程。後來被 AOL 併購之後,決定要出來做 SaaS 服務的公司 Loudcloud 。

第2章 我會活下去

第二個章節則是作者身為 Loudcloud 的執行長的過程, 1999 年創立的 Loudcloud 搭上了網際網路跟 SaaS 服務的熱潮。一年之內就成長到兩百人以上的網際網路服務公司,但是也在一年多後遇到了 2000 年的網路泡沫化的風潮。Loudcloud 的業績腰斬之外,所有的資金也都抽走。接下來就是許多執行長會遇到的過程(但是沒看過書上會寫)

  • 晚上失眠睡不著。
  • 每天為了尋找資金,有參加不完的說明會。
  • 家人完全無法兼顧,一離開公司可能就會倒閉。
  • 好不容易募資完畢,卻發現業績跟不上,面臨倒閉的危險。
  • 上市的前一天,發現網路泡沫到了谷底。可能面臨無法繼續下去的窘境。

上市後的一年,雖然業績持續成長。但是也發現整個業界其實是已經無法再成長了。於是作者在瞞著全部員工的狀況下,開始幫公司尋找著賣家。並且將公司管理伺服器的系統抽離出來,成為之後作為另外一家新創 Opsware 的主要業務。

第3章 關關難過關關過

Loudcloud 最後賣給了 EDS 公司後,作者也很順利的在瞞著大多數員工ㄉ的狀況下。將裡面的雲端 Operation 的套件獨立成新的公司 Opsware 。 所以~第一個(也唯一一個)客戶當然就是 EDS 這家公司。 當時 EDS 的導入也不順利,客戶窗口只給他們兩個月的時間導入。為了解決這個問題,他們跟窗口不段的溝通,也知道窗口其實不排斥使用 Opsware ,但是他也希望可以使用另外一套軟體 Tangram 來盤點硬體設備。所以作者就去把 Tangram 買下來來免費給客戶使用。讓客戶馬上續約。 撐過了這關之後,雖然公司歷經過兩次的大裁員,也都能順利度過並且順利成長成業界第一的領先指標。 後來許多的成長過程後,也順利賣給 HP 。

尋找賣家的時候,名言:『如果你想要辦一場賽狗比賽,那麼一定要有一個假兔子。你要提高公司賣家,一定要有一家假買家』。

第4章 愈挫愈勇

第四章後有許多身為執行長的心法,蠻多值得好好思考的。

  • 如何度過公司掙扎期
    • 別往壓力往身上攬:試著別當一個只講好消息的執行長。
    • 創業不是跳棋,而是西洋棋:除了自己產品外,別忘記看外在環境與市場。
    • 活得越久,機會越多:好像許多新創公司都會有這個狀況,最先首要的就是要不斷的活著。
    • 不必太自責
    • 玩家與專家的差別,在於遇到問題的心態:經營公司不可能一直順風順水,而遇到問題的心態才是重要的。

接下來作者也分享關於裁員的許多心理建設與好的步驟:

  • 裁員的重要性:
    • 眼觀前方
    • 不要拖延
    • 據實以告
    • 訓練主管,需要良好的跟員工溝通。
    • 公開致詞
    • 站在第一線
  • 如何開除高階主管:
    • 問題分析
    • 告知董事會
    • 告訴該主管
    • 告知全公司(並且幫該主管留餘地)

最後,作者也分享心理過程。裁員是個痛苦的抉擇,不是員工的錯誤而是公司整個決策的錯誤。 但是需要跟員工們好聚好散,並且不要自怨自艾,因為外部的人不會管理裁員公司的執行長怎麼想,重點是該如何處理完資產,儘速的重新站起來。

第5章 先管人再管產品,最後才管利潤

作者本身雖然是銷售專業起家,但是他相信公司的產品跟員工相當的重要。也就是他相當在意公司的成長需要將同仁們管理得好,才能夠做出好的產品,最後自然能夠有好的利潤。

英國國務親包爾講過:「找人才要看他的優點,而不是要求他毫無缺點。」

接下來作者分享了他對於「員工訓練」與「 1 on 1 對談的重視性」。

  • 新創員工一定要員工訓練:
    • 因為就是公司許多事情都是新的,更需要有良好的訓練手冊。來幫助業務推廣與事件處理。

這一個段落,也是我認為這本書最精華的部分。身為新創公司的創業執行長,作為業務起家的作者。不但沒有以業務作為第一宗指,客戶當作最高守則。竟然是將員工與訓練跟產品當成最重要的準則。 真的是很難得!

  • 員工訓練的重要性:
    • 生產力:員工訓練的效果,深深影響員工在職後的工作生產力。如果希望生產力夠高,就不應該忽略員工訓練。
    • 績效管理: 員工績效考核的時候,效果不好。往往是因為當初員工在職得時候沒有給予足夠的員工訓練外,也沒有告訴他應該要做到哪些事情才是「好的績效」。
    • 產品品質:好的員工訓練,才能讓大家對於好的產品品質有一致性的了解,也對於產品有更深入的了解。
    • 員工留任:員工會離職往往跟討厭主管(往往是因為主管訓練不夠,無法好好帶領員工),或是學不到東西兩者有關。而好的員工訓練往往可以減少這兩個問題的發生。讓員工更願意留下來。
  • 員工訓練的主軸:
    • 職能訓練:目的在於熟悉所有的產品,場地與形式並不是最重要的事情。
    • 執行訓練計畫:務必要讓主管們確實執行訓練計畫,如果不執行員工訓練的人,就有缺額不補人。(這有點酷!)
    • 管理人員的訓練要親自出馬:對於高階經理人員的訓練,當然要由執行長出馬。務必要讓每一個高階經理人了解公司的主要精神與目標管理。

接下來,作者也列出一系列的「產品經理指南」。其實我認為可以單獨初一本書!!

產品經理指南
  • 好的產品經理對市場,對手以及自己的產品暸若指掌。
  • 好的產品經理不會花時間跟各部門協調。(如果需要協調,代表新創公司本身的溝通不足)
  • 好的產品經理要明確定義目標
  • 好的產品經理會準備好產品的問答集,簡報與白皮書。(務必讓所有人都跟你一樣了解)。
  • 好的產品經理會使用書面表達自己的立場
  • 好的產品經理要團隊以營收以及顧客為主
  • 好的產品經理想得遠
  • 好的產品經理準備好新聞效果,幫新聞媒體摘錄重點
  • 好的產品經理凡事講得明白
  • 好的產品經理懂的自律(要有定期報告,進度報告,絕對不會省去相關事情)。

第6章 規模大了,管理難了

公司規模大了以後,往往會有「管理債」。就很像「技術債」一樣,但是這個是執行長所留下的「管理債」。

管理債
  • 一山容二虎:讓決策無法統一。
  • 加薪挽留明星員工,但是加薪過高:造成許多員工效仿。
  • 缺乏績效管理,也沒有員工回饋流程

接下來管理除了管理債之外,有一些很重要的東西。作者也是都有分享出來:

  • 將權謀算計降到最低: 透過明白清楚的獎賞制度,讓大家減少彼此算計的空間。
    • 薪酬與獎金
    • 組織設計與權責劃分
    • 升遷流程
    • 避免人云亦云
  • 將權謀算計轉換成「企圖心」
一對一面談的重要性

作者相當推崇一對一面談,也有分享務必要讓面談者暢所欲言,儘量能將自己想要表達的意見表達出來。如果希望面談有個架構,可以讓員工將他想要談得事項寄出給你。也分享出一些很值得思考的一些面談破冰題目:

  • 你覺得部門該如何改善?
  • 公司或部門最大問題是什麼?
  • 你覺得誰很有本事?誰是你崇拜的偶像?
  • 你覺得這個產品哪裡不好?
  • 你來上班快樂嗎?
企業文化的重要性

企業文化不是週五下午吃下午茶,也不是帶家裡寵物來上班。而是對於整個公司的重要性。 AMAZON 的前執行長 Bazos 透過使用門板來當會議室的門,清楚表明公司要節省來讓客戶拿到最便宜的商品。公司內部應該要有一件事情視為最重要的企業文化,從執行長到員工都能夠徹底執行的一件事情,做得好就能當成是宗教感染般的效果。

第7章 執行長定心術

執行長最難的,往往不是管理企業,不是管理員工,而是要如何管理自己的內心。如何讓自己不會朝令夕改,不會讓員工無法適從。這邊作者也建議透過以下方式來鍛鍊自己的定性。

定心術:

  • 擴展人脈
  • 想法訴諸文字
  • 尋找出路而不是尋找困難

接下來作者也解釋許多執行長的特質,該如何培養相關的特質。

身為執行長要能夠給予員工最有效率的反饋,以下作者也建議:

  • 態度真誠
  • 立意要良善
  • 不要人身攻擊
  • 不要讓對方丟臉
  • 回饋不是一體適用
  • 直接而不過分

第8章 創業第一法則:沒有法則可言

最後一個章節分享了許多身為執行長的困難點:

  • 應該要當責,還是要鼓勵坦承失敗:
    • 這邊作者建議要好看失敗的難度與可以避免程度。才能獎勵勇敢當責的人,也能撫慰完成的人。
  • 什麼時候要賣掉公司
  • 「換人做做看」管理術:這是一個解決部門爭執的想法,讓兩個部門主管交換處理,實地幫對方思考。
  • 維持高水準表現

第9章 從創業到創投

作者後來做了創投,也在這裡分享了了許多想法。並且在他的部落格跟 Podcast 與書籍都有相當多特別的想法。最後的附錄也相當的經典,裡面有:

  • 面試銷售主管的問題集
  • 營運主管的問題集

光是這兩個就很值得另外出書了。

心得:

老實的說,有聽過太多關於 a16z 的故事(主要是在 Podcast 聽到相關介紹)。但是並沒有對他們的功績如數家珍,經過這本書之後才真正地對於作者有相當深入的了解。但是讓我相當的意外的是,身為銷售起家的作者卻認為管理員工是身為新創公司最重要的事情,並且也將產品的品質當作第二重要的事情。 許多的文字間有透露出,作者認為只要產品夠好能夠解決客戶的問題,不用在乎對手與市場的面向,還是可以在獲得許多客戶的青睞。

此外,這本書有許多關於員工訓練與一對一面談相當好的見解。身為執行長,這些見解也相當的難得,也讓我真正見識到一個良好的執行長究竟該如何讓公司能夠正向成長才是。

參考網站:

  • Andreessen Horowitz - Wikipedia
  • [Andreessen HorowitzSoftware Is Eating the World](https://a16z.com/)
  • [a16z (@a16z) · Twitter](https://twitter.com/a16z?ref_src=twsrc^googletwcamp^serptwgr^author)
  • [PodcastsFuture](https://future.a16z.com/podcast-network/)

[學習心得] LINE Bot 開發者指南 詳解 - 4. LINE Login

$
0
0

前言:

各位好, 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines的投影片,考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外,並且特定用這一系列文章加以解釋,希望可以讓更多開發者有更多的了解。 Development guidelines文件內容很多,本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第四篇文章,主要講解的會是關於 LINE Login 與開發時候需要注意的事項。

文章索引:

完整投影片鏈結: https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注:

  1. 關於LINE Bot
  2. 使用Webhook URL接收請求時的注意事項
  3. 發送 API 請求時的注意事項
  4. LINE Login (本篇文章)
  5. LINE Login (補充)
  6. 其他相關功能

本篇文章將專注在第一個段落,也就是 Page 30 ~ Page 46 的部分。

LINE Login

本篇注意事項中,將會帶出以下的相關項目。

  • LINE Login 介紹
  • LINE Login authentication
  • (1) Callback URL 的設定
  • (2) 驗證與授權
  • (3) 重新導向
  • (4) 取得 access token API
  • (5) 取得 ID Token
  • (6) 取得用戶資料
  • LINE Login 處理流程
  • 透過 LINE Login 建立帳號關聯性的機制
  • 自動加好友功能 (1)
  • 自動加好友功能 (2)
  • 自動加好友功能 (3)
  • 自動加好友功能 (4)
  • 好友狀態檢查 API

以下開始將會逐一針對每一個頁面詳細解釋:

LINE Login 介紹

這一個頁面主要是介紹關於 LINE Login ,關於更詳細的 LINE Login 的簡介部分,可以透過以下的文章來了解:

許多的商業服務都會透過會員機制來提供許多專屬的優惠或是獎勵活動,但是會員的註冊與登入流程常常讓許多使用者覺得為難。除了要填寫許多的資料外,使用者還需要額外記住另外一組的帳號密碼。 LINE 在台灣的佔有率相當的高,並且幾乎每個使用者都有 LINE 的帳戶的狀況下,這時候如果能夠直接使用 LINE 帳戶來註冊與登入網站服務的話是不是相當的方便?

LINE Login 除了提供一個方式來登入之外,也可以提供使用者名稱,大頭照的相關資訊。並且透過 LINE Login 也可以同時讓使用者加入商業服務的 LINE官方帳號,讓使用者更無時無可都可以使用到相關的服務。

相關文章

-如何透過 Golang 開發 OAuth2 的 PKCE – 以 LINE Login 為例

LINE Login authentication

而在提到關於 LINE Login 的認證流程詳細解釋,基於 OAuth2 與 OpenID 協議的 LINE Login 不僅僅可以打造一個安全沒有疑慮的登入服務外,還可以幫助網站的開發者快速打造相關的服務。

相關文章

(1) Callback URL 的設定

關於 Callback URL 的設定上,這邊有一些相關資訊。

  • Callback URL 必須符合 HTTPS 。
  • 伺服器本身必須要符合 TLS 1.2 與 1.3 。
  • 如果需要支援一個以上的 Callback URL,請記得使用換行來分隔。

相關文章

(2) 驗證與授權

關於 LINE Login 的認證網址,有相當多的相關參數可以使用。大概講幾個比較容易被開發者使用到的參數。

  • prompt: 透過這個參數可以強制性跳出,使用者同意的簽署頁面。可以了解該 App 目前需要哪些權限。
  • bot_prompt : 可以將你的 LINE Login App 跟 LINE 官方帳號綁定。也就是使用者登入完成後,可以直接將官方帳號加成好友。

更多的相關使用方式與範例可以參考: Add a LINE Official Account as a friend when logged in (bot link).

相關文章

(3) 重新導向後的資料處理:

這篇投影片提到了,當使用者輸入完帳號跟密碼完成 LINE Login 註冊之後。 LINE 平台會將結果發送到 Callback URL 所登記的伺服器。這時候會收到相關的資訊需要做後續的處理。

這時候會有兩種方式可以取得,也就是接下來兩頁投影片的方式:

  • 取得 Access Token API
  • 取得 ID Token

此外,如果在手機端開發 LINE Login 請記得要使用 PKCE 的呼叫認證方式。讓您的安全性更加全面。 細節可以參考 如何透過 Golang 開發 OAuth2 的 PKCE – 以 LINE Login 為例或是技術文件 PKCE support for LINE Login

相關文章

(4) 取得 access token API

這邊討論取得 Access Token API 呼叫需要注意的參數,相關文章介紹一樣可以參考 如何透過 Golang 開發 OAuth2 的 PKCE – 以 LINE Login 為例,也可以查看技術文件 Getting an access token with a web app

相關文章

(5) 取得 ID Token

取得 ID Token 的前提是必須使用 scopeopenid,才能在收到 response 的時候收到。收到 id_token後有兩個方式可以取得使用者資訊:

相關文章

(6) 取得用戶資料

這邊指的是透過 Get User Profile的方式來取得使用者的資料,但是這邊需要事先取得 Access Token 也就是在 Request Access Token 完成後的資訊才可以。

相關文章

LINE Login 處理流程

這邊也有另外一張圖型顯示一樣的事情,主要就是 “Request Access Token” 之後,有以下兩種狀況:

  • 使用 scopeopenid,才能在收到 response 的時候收到,收到 id_token,可以直接取得使用者資訊。
  • 如果沒有 id_token可以透過 access token 再去取得 Get User Profile 來取得相關資訊。

相關文章

自動加好友功能 (1)

在建立 LINE Login Channel 的時候,當初的設定「將 Bot 加入好友選項」有啟動的話,可以將官方帳號一起加入成好友。 本篇投影提供更多相關的參考資料:

【必要的設定】

•要啟用將Bot加成好友的選項時,必須執行「將Bot連結到LINE Login channel」的作業。

【啟用選項的要件】

  • 具有被授予LINE Login使用權限(「WEB」或「NATIVE_APP」)的channel。
  • 至少存在一個以上的Bot,Bot的Messaging API channel和LINE Login channel是隸屬同Provider。
  • 進行設定的用戶,具有在LINE Official Account Manager關聯的官方帳號Admin權限。**
  • 進行設定的用戶,具有在LINE Developers中的** Loginchannel Admin權限

【注意事項】

  • 登入時選擇加成好友則和官方帳號關係將被更新。
  • 原則上在選擇官方帳號時,除了該channel的正式官方帳號以外,禁止與其餘官方帳號建立關聯性。
  • 由於更新會立即反映,因此為了避免誤設到其他帳號(測試帳號等),請在操作時特別小心。
  • 如果LINE Login channel是建立在Certified Provider之下,則預設值將會是已勾選加成好友(解除封鎖)的狀態。

【關於 bot_prompt 參數的介紹】

  • normal: 透過設定方式,提供使用者自己選擇是否要加入官方帳號為好友。
  • aggresive: 比較積極的方式,透過多彈出一個視窗,可以讓使用者來加入好友。(如果前一個頁面沒有加入的話)。

好友狀態檢查 API

如果跑完 LINE Login 是否還有方式可以知道使用者有沒有把官方帳號加入為好友呢? 就可以使用這個 friendship_status_changed的參數來了解。

參考資料:

結論:

以上就是「LINE Bot 開發指南」第四部分的補充與分享,想要知道更多內容可以查看完整投影片,或是找到其他篇的文章來了解。

想了解更多開發者的活動? 立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev img

Viewing all 540 articles
Browse latest View live