[TIL] 生成式 AI (Generative AI) 相關新聞跟應用 2023/03/17

Screenshot Microsoft 365 Copilot

前情提要:

因為最近的 Generative AI 相當紅(還有 ChatGPT) ,開始搜集一些相關資料。作為我 Twitter 資訊的整理。

相關資訊

大多是轉貼資訊,搜集起來作為自己查詢用。

(轉)AI 資訊大爆發的一週,大多數人可能只關注到 OpenAI、Google 跟 Microsoft Copilot。不過,其實還有滿多其它的訊息。週一

週二

週三

週四

  • Microsoft 365 Copilot
  • Science (Vol 379, Issue 6637) 正式刊出 Meta AI (FAIR) 用他們開發的 LLM - ESMFold 預測原子級蛋白質結構

[好書分享] 阿共打來怎麼辦

阿共打來怎麼辦
你以為知道但實際一無所知的台海軍事常識
 共 597 人評分
作者: 王立  沈伯洋  出版社:大塊文化 
出版日期:2021/12/28

買書推薦網址:

前言:

這是 2023 年第三本讀完的書,當初會買這一本書,當然也是因為在台灣大選之前,每次都有相關的軍事謠言會出現。 甚至國外的同事還會很緊張的來詢問台灣的狀況,這樣的緊張狀況其實也是會讓台灣的人緊張的。但是放下心好好的思考過後,也會想要知道如果真的要打過來,究竟會怎麼打? 到底有沒有機會打得贏呢? 這就是買這一系列書的原因,其實當時有不少書有推薦。不過這一本真的把所有經常聽到的「謠言」加以詳細探討,真的相當的有趣。

內容摘要:

你所知道的軍事情報大都是謠言
重新建立對台海軍事現況的認知

破除常見的攻台軍事謠言
1|彈道飛彈無敵論
2|千台無人機癱瘓防禦論
3|空降部隊奇襲斬首論
4|直升機快速打擊部隊斬首論
5|民航機奪取機場論
6|萬船齊發攻台論
7|航空母艦夾擊論(台灣東部淪陷論)
8|貨櫃改裝飛彈船突襲論(美軍航母擊沉論)
9|近年正夯的巡弋飛彈與長程火箭彈襲台論
10|萬年不變的經典謠言——封鎖台灣

◎ 破解多年來流傳的各種軍事謠言,建立基於事實根據的軍事常識。
◎ 處在緊張的美中對峙,美日歐澳印圍中勢態,台灣處在第一線,必須更清楚理解我們所在的實際處境。
◎ 培養基礎常識,判斷局勢變化,不被各種假訊息、資訊戰謠言牽著走,免得順了對手的意。

第一部 破除常見的攻台軍事謠言

首先就先列舉出許多常聽到的進攻台灣的軍事謠言,不論是:

  • 彈道飛彈攻台論:
  • 千台無人機癱瘓防禦論
  • 空降部隊奇襲斬首論
  • 萬船齊發攻台論
  • 萬年不變的經典謠言──封鎖台灣

這些謠言都建立在大陸的資源眾多的狀況下,但是真正的事實卻是:

  • 台灣海峽真的是真正屏障。
  • 要起飛過來做任何投彈與搶灘動作,都會有相當程度的犧牲。
  • 空降部隊要能順利斬首,要能做到沒有任何空軍基地起飛攔截。但是真正戰爭起來,就算總統罹難,也有很多代位元首會繼續執行。而且空降部隊相當容易淪為絞肉,來一個殺一個。幸運能夠降落的將是相當稀少。
  • 封鎖台灣如果真正發生,不光是台灣。 日本,韓國甚至是整個東南亞的航運都會受到引響。大陸不可能不理每個國家的抗議。

並且所有的事實,還屏除掉美國跟日本完全不管台灣生死的狀況下。如果有這兩個國家的介入,整個進攻台灣的流程不可能更簡單。

第二部 中國侵略台灣的戰術

接下來就是真正到兵推的階段,認真的來探討如果中國真的要侵略台灣。那會有哪些戰術,分別為:

  • 如何搶下幾個致勝點
  • 要從哪些地方登陸
  • 登陸後應該要如何解除台灣的軍事狀態
  • 之後要如何推進到全台灣

這些的路程究竟要如何才能真正地打侵略台灣的流程,真正仔細來探討下去。才會了解整個流程可能造成的重大傷亡與難度。

第三部 持續進行中的戰爭

其實中國侵略台灣早就開始,我們觸及可見的就是資訊戰。除了資訊戰之外,如果真正戰爭持續下去,會有哪些事情:

  • 戰爭不是馬上斷垣殘壁,後勤補給與持續佔領全部台灣土地
  • 除了登陸戰爭外,還有哪些方式?
  • 封鎖與經濟作戰,會有哪些方式。

第四部 台灣以及周邊各國的真實戰略構想

這邊提到跟台灣的安危有相關的周遭國家,如果在中國侵略台灣發生的時候。 他們會有哪些的影響。

心得:

如同作者在書中的結語,就是真正坐下來認真的思考過後。真正與認真的將所有侵略台灣的方式加以分析之後,你就會知道侵略台灣本身真的有相當程度的吃力不討好。那麼,為什麼會有哪麼多的謠言與資訊戰呢? 因為謠言與資訊戰是最少損傷,並且最容易造成台灣加以分裂的作戰方式。 所以我們不能怕戰爭,卻也不應該不緊張。 面對著謠言更不應該害怕與恐懼,並且要認真的思考所有謠言的背後想要造成的混亂與分裂。

世界上最大傷害,往往就是恐懼與分裂。我們唯有更加的團結,才能讓我們的身家安全更有保障。

[學習心得][Golang] 把 Github Issue 當成資料庫來用

x-cellent technologies GmbH

前提

之前說過許多資料庫都已經開始收費了,所以想要找一個免費的資料庫來使用的其實相當麻煩。不論是使用 Heroku 或是 Render 的資料庫其實都是一筆不小的費用。 所以,常常動歪腦筋到一些奇怪的儲存體來當資料庫,今天這一篇文章將透過 Github Golang 的 API 來將你個人的隱私 (Private Repository) 的 issue 來當成資料庫來使用。

開源套件 https://github.com/google/go-github

將儲存資料獨立開來的套件 User Favorite Database - FavDB

2023/05/31 這裡也整理了一個我獨立出來的套件 https://github.com/kkdai/favdb ,功能如下:

  • 用同一個資料處理邏輯可以同時處理 Memory DB , PostgresSQL 跟 Github Issue
  • 如果一開始找不到可靠(免費)的資料庫,可以先用 Memory DB 作為前期開發用。
  • 後期馬上改成 PostgresSQL 或是 Github Issue 都不用大改程式碼。

如何取得 Github Token

首先要使用 Github 的 API ,你需要取得 Github Token ,這裡附上流程:

image-20230216161642112

打開設定

image-20230216161706554

選到開發者選項 (Developer settings)

image-20230216161756251

這邊選 Personal Access Token ,記得選 Tokens (Classic)

如此就可以取得一個開發者的 Access Token ,記得不要搞丟了。(或是不要存在 github 上面)

使用 Github Issue 當成資料庫的前提與方法

API Rate Limit

如果想要使用這樣方式當成資料庫的人,首先對於你的資料格式要相當的簡單。或者是說你的資料存取是比較低流量的。因為 Github API 具有 Rate Limit 相關資訊可能如下:

  • Core:
    • Limit: 5000 (60mins)
  • Search:
    • Limit: 30 (60mins)
  • GraphQL:
    • Limit: 5000 (60mins)

資料擺放的建議

  • Title: 資料庫名稱
  • 每一個 comment 可以當成是一筆 record
  • 每一個 Comment 可以透過 csv (逗號來分隔),或是透過其他方式來分隔資料。
  • Tag 可以讓你快速找到類似的 Title

這些只是一些建議,以下的程式碼範例作法更加的簡單。 只是一個 Key -> Value 的方式來存放。 Key 放在 Title ,而 Value 就直接放在第一個 Comment 裏面。

相關程式碼:

基本結構

type GithubDB struct {
	Name   string // github 擁有者名字
	Repo   string // repo 名稱(可以使 private)
	Token  string // 剛剛取得的 Access Token
	Client *github.Client
}

初始化 Github Client

func createGithubClient(token string) *github.Client {
	ctx := context.Background()
	ts := oauth2.StaticTokenSource(
		&oauth2.Token{AccessToken: token},
	)
	tc := oauth2.NewClient(ctx, ts)
	return github.NewClient(tc)
}

儲存 Github Issue (Create)

這時候需要給 使用者名稱 NameRepo 名字。

func (u *GithubDB) saveIssue(title, body string) error {
	input := &github.IssueRequest{
		Title:    String(title),
		Body:     String(body),
		Assignee: String(""),
	}

	_, _, err := u.Client.Issues.Create(context.Background(), u.Name, u.Repo, input)
	if err != nil {
		fmt.Printf("Issues.Create returned error: %v", err)
		return err
	}
	return nil
}

尋找 Title (key) Get by Title

func (u *GithubDB) getIssue(title string) (string, int, error) {
	ret, _, err := u.Client.Search.Issues(context.Background(), title, nil)
	if err != nil {
		fmt.Printf("Issues.search returned error: %v", err)
		return "", 0, err
	}

	log.Println("issue ret:", ret)
	for _, v := range ret.Issues {
		log.Println("return issue:", v)
		log.Println("Issue Num:", v.Number)
		log.Println("Body:", v.Body)
		log.Println("Comments:", v.Comments)
	}
	return *ret.Issues[0].Body, *ret.Issues[0].Number, nil
}

更新裡面的資料 (Update)

func (u *GithubDB) updateIssue(number int, title string, updatedCnt string) error {
	updateIssue := &github.IssueRequest{
		Title:    String(title),
		Body:     String(updatedCnt),
		Assignee: String(""),
	}
	ret, _, err := u.Client.Issues.Edit(context.Background(), u.Name, u.Repo, number, updateIssue)
	if err != nil {
		fmt.Printf("Issues.edit returned error: %v", err)
		return err
	}

	log.Println("Issue updated:", ret)
	return nil
}

未來發展

其實在做一些簡單的範例程式的時候,如果你資料庫本身沒有太多的欄位需求。本身的存取量也不是很大,或許可以考慮透過 Github Issue 來存放你的資料。一來你的資料庫都是「可視化」,你也可以節省一些不需要的額外開銷。

[電玩][PS5] 地平線 西域禁地)全破心得

Image

地平線 - 西域禁地全破心得:

由於地平線第一代我很喜歡(當初有買 DLC) 也破了,這次二代西域禁地一放出風聲。我馬上就買了 PS4 普通版。比較讓我驚喜的是,後來運氣很好買到PS5之後,換了 PS5 搖桿真的是有相當驚喜的表現:

  • 有多了相當多種類的震動規格,不論是土地震動,小寶物跑出來,大型機器獸的出場都讓人驚艷。
  • 有力回饋的按鈕讓你在射弓箭的時候,更加的好用。甚至需要敲開某些東西的時候,R2 會相對應的變得很難壓下去。
  • 關於攻略部分,因為支線任務太喜歡玩了。主線打王的時候,不小心等級升到 50 級,默默的碾壓過去。
  • 關於攻擊部分:
    • 屬性弱點很重要,記得要先射滿屬性弱點開始打。
    • 拆解部位有點麻煩,許多重要零件都要先射下來。
    • 標槍還是最好用的,一直射一直爽。

最後結尾有很大伏筆,接下來就要等四月的 DLC Burning Shores

[好書分享] 丼丼丼丼丼 - 日本五大丼飯誕生祕辛!

丼丼丼丼丼
日本五大丼飯誕生祕辛!
 共 27 人評分
作者: 飯野亮一  譯者: 陳嫺若  出版社:臺灣商務印書館 
出版日期:2021/09/01 

買書推薦網址:

前言:

這是 2023 年第二本讀完的書,當初會購買這本書就是肚子餓(不是) 因為即將準備去日本旅遊,想要了解一下日本的丼(要唸作 ㄉ ㄢ v)究竟有什麼樣的歷史。整本書的內容摘要相當有趣,就讓人想要買下來慢慢閱讀一下相關的知識了。

此外,這本書很需要日本年號跟西元年份的對照表:

image-20230120180532496

內容摘要:

1.透過史料,了解熱門的天丼.豬排丼.牛丼.鰻魚丼.親子丼誕生過程
2.以富有歷史感的圖片呈現丼飯誕生時景況
3.闡述各種丼飯早期的食用方法及食材

探索江戶時代,風靡全日本的庶民美食
品嘗充滿飯香的跨時代歷史風味

原本被當作下酒菜的蒲燒鰻,如何搖身一變成為日本最早的丼飯?
原本不吃雞肉的日本人,如何發明出國民美食親子丼?
原本來自海外的牛,如何受到歐洲人影響轉變為日本食材?
原本薄薄的豬肉排,又是如何增加厚度,甚至改名為炸豬排?

天丼•豬排丼•牛丼•鰻魚丼•親子丼,五種在民間掀起熱潮的丼飯,但你很可能不知道它們的由來。

本書追溯從江戶時期到明治時期的軼聞趣事,探索日本國民如何爭相倣效丼飯作法,以及享用丼飯的熱切心境。想一窺大和庶民生活核心,領略日本邁向近代的驅動力,就從了解這五種丼飯開始!

丼飯出現以前

丼(念為“膽”)飯出現之前,其實江戶從 1805 年就開始有吃茶泡飯的過程。(原來茶泡飯那麼早啊)。

鰻魚丼的誕生

蒲燒鰻魚很早就開始在日本出現(1688~1704) 年,就開始出現在江戶高級餐廳之中。之後在 1777 年開始有蒲燒魚加上白飯的餐點。

在 1804 年的琾町的贊助者 - 太久保今助因為喜歡吃鰻魚,所以把它用飯放在一起吃。這個據說就是鰻魚飯起始。

那麼鰻魚丼是如何開始的呢?

1837 年開始京都跟大阪將鰻魚飯叫做 (Mabushi) 也就是鰻魚丼飯的簡稱。大概的價錢是: 200 文。 裡面主要是五六條小鰻魚去頭後,烤起來。

值得注意的是雖然說,筷子的用法是來自於中國。但是 免洗筷也就是吃完就可以丟掉的筷子,卻是來自於日本的。因為在當時江戶與京都的鰻魚丼飯都是有附上不回收的筷子。並且醬汁也從京都的比較濃的醬油口味,逐漸變成了甜的口感。

image-20230121183636862

當時日本普燒鰻魚飯的排行(嘉永六年)

天丼的誕生

天丼也就是天婦羅的丼飯,在一開始天婦羅也是單獨吃的。 但是因為在日本橋的天婦羅的吉兵衛,因為他的天婦羅太好吃,旁變得蕎麥麵也變成是一起的爆紅。變成了日本橋周遭的名店,那時候的天婦羅也都是搭著蕎麥麵來一起販賣的。

但是從 1797 年開始,許多的茶泡飯店家都已經有搭著販賣天婦羅。後來受到大舉的歡迎,甚至也有了天婦羅專賣店。裡面在 1874 年也開始有了「天丼」這個名字的產生。那時候的天丼也就是把天婦羅沾了醬汁,或是稍微泡過後放在飯裡面一起端上來。這時候的做法也跟現在的天丼沒有太大的差別。

image-20230121183544060

天丼的菜單

親子丼的誕生

講到親子丼(也就是將雞入與雞蛋放在一起的伴著飯一起吃)的歷史故事更是相當的有趣。日本其實從兩千年前就開始養雞,但是在西元 675 年當時的天武天皇頒發了不准吃牛,馬,狗,猴肉跟雞肉的法律。 所以一開始的時候,日本人養雞是為了他的雞蛋當作營養來源。卻不是為了雞肉本身。幾百年下來,甚至在許多故事裡面都有了吃雞肉會有處罰與破戒的故事產生。

到了江戶時代(西元: 1626 年)左右開始在當時的書籍看到了關於雞肉的料理。但是那時候雞肉還是算是比較下等的禽類食物,甚至是到了江戶時代出現的「親子蔥花面」裡面用的是雁肉加上雞蛋,而不是雞肉。在那蛇後,鴨子,雁子與雞蛋算是上等,而雞肉算是下等(黑人問號)。

到了西元 1854 年由於鎖國開放之後,雞肉的用量開始大增。日本的雞肉養殖業也開始興盛。「親子丼」也是在這個時候出現大約是在1880 年左右。

牛丼的誕生

牛丼在現在算是日本的國民美食,但是就像前面有提到的天武天皇有了禁殺令之後。牛也是不能屠殺的動物之一。也是到了幕末鎖國開放之後,在外國文化的進來改變後,牛肉才變成是日本知名的美食。

一開始也是從牛肉火鍋開始的,江戶時期的後期就有獸肉火鍋。

關東大地震(西元: 1923)年之後,由於日本東京傷亡相當嚴重,甚至各地都有死傷的報告出現。當初許多逃出的人,身上並沒有太多的食物可以做,就將牛肉加上飯來販賣也就是後來牛丼的產生。

豬排飯的誕生

而豬排飯也是跟牛丼有類似的故事,也是從豬肉火鍋變成豬排飯。(當時還是薄薄的一片),後來才加上了透過雞蛋與沾粉去油炸的豬排。這也是豬排飯的產生。

心得:

這一本書相當的有趣,裡面有許多古代文物與當時的菜單與相關的新聞。可以看出作者真的很細心地將相關的丼飯歷史都調查清楚了。 也讓人知道日本的美食是經過哪一些的人文,歷史與相關的時代變遷的結果。 不看這本,真的不會知道以下的相關事項:

  • 丼飯裡面,第一個出現的是鰻魚丼。
  • 天婦羅丼飯,一開始是搭配茶泡飯來販賣的。後來才搭著白飯。
  • 親子丼飯其實一開始都不是使用雞肉,大多是雁肉跟鴨肉,搭配雞蛋。
  • 日本人有很多年其實是不能吃牛肉跟豬肉的。

真的蠻有趣的,推薦大家來看。裡面也有談到相關醬汁的變遷與做法。看了肚子會餓。

[學習心得][Golang] 如何透過 Golang 的 Interfaces 達成繼承inheritance) 的效果 - 用 LINEbot 連接不同資料庫為例子

前提

平常在準備 LINE Bot 的相關範例程式碼的時候,通常都是沒有加上資料庫。但是有一些的範例程式碼其實有一些儲存資料會比較好。 所以這時候需要加上資料庫的相關讀寫。

當然…. 資料庫也是有窮人版的。由於許多服務都要對於他們的資料庫服務收費之後,這時候就需要有一些變通的方式。 使用記憶體當作資料庫的架設。

那如何讓你在程式碼中,只要寫一次關於資料處理方面,當你的部屬的環境變數有不同,就會使用不同的資料庫來存取呢?

比如說:

  • 當你有 PostGresSQL 的資料庫 URL ,就使用 PG SQL 相關處理方式。
  • 如果沒有的話,就使用記憶體做為資料庫。
  • 以後也可以增加不同的雲的部署方式。(或是支援 Firebase 相關資料庫)

這一篇文章將開始敘述,如何透過 Golang 的 Interfaces 的方式來達到類似繼承的效果。 使用同一份的程式邏輯程式碼,可以根據你設定的參數不同來讀取不同得資料庫。

範例程式碼 LINE Bot 群組聊天摘要生成器

這次透過上一次的範例文章 [學習文件] LINE Bot 群組聊天摘要生成器 作為一個範例程式碼。 先來看整體切割方式。

Github Repo: https://github.com/kkdai/LINE-Bot-ChatSummarizer

## 資料架構切割圖

image-20230113221237698

所有的 implement 都是透過 Data 也就是之後 Basic Class 的 API 來存取相關資料。 只要建立的時候,使用相關的 Interfaces 搭配不同的起始變數就可以呼叫同樣的處理資訊。

先列出相關的處理程式碼:

相關處理程式碼

這裡使用到定義成 Interfaces 的 GroupDB 的實作,根據不同的設定 NewPGSql(url) 或是 NewMemDB() 就可以讓裡面對應的實作不同。

詳細列出不同資料庫的開發方式

接下來列出不同資料庫的實作方式。

Basic (Data)

這是最基礎的設定,最重要記事 interface GroupDB 的宣告,然後其他兩個也必須要有

  • ReadGroupInfo(string) GroupData
  • AppendGroupInfo(string, MsgDetail)

兩個 function 的實作,並且輸入參數跟輸出參數都要相同。 這樣才能使用到一樣的邏輯來操作資料。

Memory DB

接下來這是使用 Memory 做為資料庫的實作,可以看到主要是透過 map 來操作相關資料處理。 這樣透過 memory 當作 DB 的方式,如果是在 FAAS (e.g. Heroku 或是 Render.com) 就會在服務睡眠的時候,失去你的儲存資料。

PostGresSQL DB

接下來這邊就是使用 PostGresSQL 的實作,主要是透過 "github.com/go-pg/pg/v10" 這個套件的版本,可以透過 ORM 的方式直接去操作 PostgresSQL 可以讓許多實情省下麻煩。但是很多時候,沒有直接使用 SQL 其實也是更加的麻煩。

這邊的開發流程上,沒有要注意的事情。只需要注意到必須以下實作就好。

  • ReadGroupInfo(string) GroupData
  • AppendGroupInfo(string, MsgDetail)

img

未來發展

透過 Interfaces 來當作資料庫存取的開發方式可以很方便,並且留下未來許多資料庫的資源空間。不論是支援 MongoDB 或是想要使用 MySQL 甚至是整個資料庫搬到 FireStore 也不需要改動我原版的商業邏輯部分。 只需要把基本的資料庫實作完成即可。

希望這篇文章可以給大家一些想法。