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

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

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

其實有圖書館都有免費的電子書可以借,各位可以來相關網站去借。 而且那些圖書館又可以線上辦證,不必一定要是該縣市居民,等於只要在家辦辦帳號,就可以享有這些免費資源。這些圖書館包括了 國立臺灣圖書館 / 台北市立圖書館 / 新北市立圖書館 / 台中市立圖書館 等等。裡面其實有更種書籍,但是個人推薦可以借電子雜誌,因為台北好讀的 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

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

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

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

參考文章

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

前言:

各位好, 我是 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. LINE Login (補充)
  6. 其他相關功能

本篇文章將專注在第一個段落,也就是 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

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

前言:

在二月份文章有提到 使用 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 開發者指南 詳解 - 1. 關於 LINE Bot

前言:

各位好, 我是 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. LINE Login (補充)
  6. 其他相關功能

本篇文章將專注在第一個段落,也就是 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 之間的相關性,接下來將為讀者詳細解釋:

  • 首先使用者對於官方帳號(LINE Bot) 所做的所有動作,都有相關的訊息透過 Webhook 來傳給開發者的 LINE Bot 。
  • LINE Bot 收到訊息後,可以透過取得的 Access Token 來通過伺服器認證來發送訊息給使用者。
  • 透過 LINE Login 的認證部分也可以將使用者鏈結到相關 LINEE Bot 帳號。( e.g. 透過網路商城的第三方登入 LINE Login ,可以讓使用者登入網路商城後,也直接加入 LINE Bot )。

此外,這一張投影片也希望帶給各位關於 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

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

前言:

前幾天的文章中 [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

相關文章:

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

什麼時候是好時候:掌握完美時機的科學祕密
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部 同步與思考

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

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

團隊中協調技巧:

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

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

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

心得:

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

參考文章