前情提要: 因為最近的 Generative AI 相當紅（還有 ChatGPT) ，開始搜集一些相關資料。作為我 Twitter 資訊的整理。 相關資訊 大多是轉貼資訊，搜集起來作為自己查詢用。 （轉）AI 資訊大爆發的一週，大多數人可能只關注到 OpenAI、Google 跟 Microsoft Copilot。不過，其實還有滿多其它的訊息。週一 Stanford Alpaca 7B 週二 OpenAI GPT-4 Anthropic 釋出 Claude Google 推出 PaLM API 並引入 Vertex AI 平台 Google 在 Workspace 引入 GAI AdeptAI 募得 $350M Lightning AI 支援 Fabric 週三 Meta 發起的開源專案 PyTorch 釋出 2.0 MidjourneyV5 百度推出文心一言 週四 Microsoft 365 Copilot Science (Vol 379, Issue 6637) 正式刊出 Meta AI (FAIR) 用他們開發的 LLM - ESMFold 預測原子級蛋白質結構

阿共打來怎麼辦 你以為知道但實際一無所知的台海軍事常識 共 597 人評分 作者： 王立 沈伯洋 出版社：大塊文化 出版日期：2021/12/28 買書推薦網址： Readmoo: 購買網址 前言: 這是 2023 年第三本讀完的書，當初會買這一本書，當然也是因為在台灣大選之前，每次都有相關的軍事謠言會出現。 甚至國外的同事還會很緊張的來詢問台灣的狀況，這樣的緊張狀況其實也是會讓台灣的人緊張的。但是放下心好好的思考過後，也會想要知道如果真的要打過來，究竟會怎麼打？ 到底有沒有機會打得贏呢？ 這就是買這一系列書的原因，其實當時有不少書有推薦。不過這一本真的把所有經常聽到的「謠言」加以詳細探討，真的相當的有趣。 內容摘要： 你所知道的軍事情報大都是謠言 重新建立對台海軍事現況的認知 破除常見的攻台軍事謠言 1｜彈道飛彈無敵論 2｜千台無人機癱瘓防禦論 3｜空降部隊奇襲斬首論 4｜直升機快速打擊部隊斬首論 5｜民航機奪取機場論 6｜萬船齊發攻台論 7｜航空母艦夾擊論（台灣東部淪陷論） 8｜貨櫃改裝飛彈船突襲論（美軍航母擊沉論） 9｜近年正夯的巡弋飛彈與長程火箭彈襲台論 10｜萬年不變的經典謠言——封鎖台灣 ◎ 破解多年來流傳的各種軍事謠言，建立基於事實根據的軍事常識。 ◎ 處在緊張的美中對峙，美日歐澳印圍中勢態，台灣處在第一線，必須更清楚理解我們所在的實際處境。 ◎ 培養基礎常識，判斷局勢變化，不被各種假訊息、資訊戰謠言牽著走，免得順了對手的意。 第一部　破除常見的攻台軍事謠言 首先就先列舉出許多常聽到的進攻台灣的軍事謠言，不論是： 彈道飛彈攻台論： 千台無人機癱瘓防禦論 空降部隊奇襲斬首論 萬船齊發攻台論 萬年不變的經典謠言──封鎖台灣 這些謠言都建立在大陸的資源眾多的狀況下，但是真正的事實卻是： 台灣海峽真的是真正屏障。 要起飛過來做任何投彈與搶灘動作，都會有相當程度的犧牲。 空降部隊要能順利斬首，要能做到沒有任何空軍基地起飛攔截。但是真正戰爭起來，就算總統罹難，也有很多代位元首會繼續執行。而且空降部隊相當容易淪為絞肉，來一個殺一個。幸運能夠降落的將是相當稀少。 封鎖台灣如果真正發生，不光是台灣。 日本，韓國甚至是整個東南亞的航運都會受到引響。大陸不可能不理每個國家的抗議。 並且所有的事實，還屏除掉美國跟日本完全不管台灣生死的狀況下。如果有這兩個國家的介入，整個進攻台灣的流程不可能更簡單。 第二部　中國侵略台灣的戰術 接下來就是真正到兵推的階段，認真的來探討如果中國真的要侵略台灣。那會有哪些戰術，分別為： 如何搶下幾個致勝點 要從哪些地方登陸 登陸後應該要如何解除台灣的軍事狀態 之後要如何推進到全台灣 這些的路程究竟要如何才能真正地打侵略台灣的流程，真正仔細來探討下去。才會了解整個流程可能造成的重大傷亡與難度。 第三部　持續進行中的戰爭 其實中國侵略台灣早就開始，我們觸及可見的就是資訊戰。除了資訊戰之外，如果真正戰爭持續下去，會有哪些事情： 戰爭不是馬上斷垣殘壁，後勤補給與持續佔領全部台灣土地 除了登陸戰爭外，還有哪些方式？ 封鎖與經濟作戰，會有哪些方式。 第四部　台灣以及周邊各國的真實戰略構想 這邊提到跟台灣的安危有相關的周遭國家，如果在中國侵略台灣發生的時候。 他們會有哪些的影響。 心得: 如同作者在書中的結語，就是真正坐下來認真的思考過後。真正與認真的將所有侵略台灣的方式加以分析之後，你就會知道侵略台灣本身真的有相當程度的吃力不討好。那麼，為什麼會有哪麼多的謠言與資訊戰呢？ 因為謠言與資訊戰是最少損傷，並且最容易造成台灣加以分裂的作戰方式。 所以我們不能怕戰爭，卻也不應該不緊張。 面對著謠言更不應該害怕與恐懼，並且要認真的思考所有謠言的背後想要造成的混亂與分裂。 世界上最大傷害，往往就是恐懼與分裂。我們唯有更加的團結，才能讓我們的身家安全更有保障。

前提 之前說過許多資料庫都已經開始收費了，所以想要找一個免費的資料庫來使用的其實相當麻煩。不論是使用 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 ，這裡附上流程： 打開設定 選到開發者選項 (Developer settings) 這邊選 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 //...

地平線 - 西域禁地全破心得： 由於地平線第一代我很喜歡（當初有買 DLC) 也破了，這次二代西域禁地一放出風聲。我馬上就買了 PS4 普通版。比較讓我驚喜的是，後來運氣很好買到PS5之後，換了 PS5 搖桿真的是有相當驚喜的表現： 有多了相當多種類的震動規格，不論是土地震動，小寶物跑出來，大型機器獸的出場都讓人驚艷。 有力回饋的按鈕讓你在射弓箭的時候，更加的好用。甚至需要敲開某些東西的時候，R2 會相對應的變得很難壓下去。 關於攻略部分，因為支線任務太喜歡玩了。主線打王的時候，不小心等級升到 50 級，默默的碾壓過去。 關於攻擊部分： 屬性弱點很重要，記得要先射滿屬性弱點開始打。 拆解部位有點麻煩，許多重要零件都要先射下來。 標槍還是最好用的，一直射一直爽。 最後結尾有很大伏筆，接下來就要等四月的 DLC Burning Shores

丼丼丼丼丼 日本五大丼飯誕生祕辛！ 共 27 人評分 作者： 飯野亮一 譯者： 陳嫺若 出版社：臺灣商務印書館 出版日期：2021/09/01 買書推薦網址： Readmoo: 購買網址 前言: 這是 2023 年第二本讀完的書，當初會購買這本書就是肚子餓(不是) 因為即將準備去日本旅遊，想要了解一下日本的丼（要唸作 ㄉ ㄢ v)究竟有什麼樣的歷史。整本書的內容摘要相當有趣，就讓人想要買下來慢慢閱讀一下相關的知識了。 此外，這本書很需要日本年號跟西元年份的對照表： 內容摘要： 1.透過史料，了解熱門的天丼．豬排丼．牛丼．鰻魚丼．親子丼誕生過程 2.以富有歷史感的圖片呈現丼飯誕生時景況 3.闡述各種丼飯早期的食用方法及食材 探索江戶時代，風靡全日本的庶民美食 品嘗充滿飯香的跨時代歷史風味 原本被當作下酒菜的蒲燒鰻，如何搖身一變成為日本最早的丼飯？ 原本不吃雞肉的日本人，如何發明出國民美食親子丼？ 原本來自海外的牛，如何受到歐洲人影響轉變為日本食材？ 原本薄薄的豬肉排，又是如何增加厚度，甚至改名為炸豬排？ 天丼•豬排丼•牛丼•鰻魚丼•親子丼，五種在民間掀起熱潮的丼飯，但你很可能不知道它們的由來。 本書追溯從江戶時期到明治時期的軼聞趣事，探索日本國民如何爭相倣效丼飯作法，以及享用丼飯的熱切心境。想一窺大和庶民生活核心，領略日本邁向近代的驅動力，就從了解這五種丼飯開始！ 丼飯出現以前 丼（念為“膽”）飯出現之前，其實江戶從 1805 年就開始有吃茶泡飯的過程。（原來茶泡飯那麼早啊）。 鰻魚丼的誕生 蒲燒鰻魚很早就開始在日本出現（1688~1704) 年，就開始出現在江戶高級餐廳之中。之後在 1777 年開始有蒲燒魚加上白飯的餐點。 在 1804 年的琾町的贊助者 - 太久保今助因為喜歡吃鰻魚，所以把它用飯放在一起吃。這個據說就是鰻魚飯起始。 那麼鰻魚丼是如何開始的呢？ 1837 年開始京都跟大阪將鰻魚飯叫做 (Mabushi) 也就是鰻魚丼飯的簡稱。大概的價錢是： 200 文。 裡面主要是五六條小鰻魚去頭後，烤起來。 值得注意的是雖然說，筷子的用法是來自於中國。但是 免洗筷也就是吃完就可以丟掉的筷子，卻是來自於日本的。因為在當時江戶與京都的鰻魚丼飯都是有附上不回收的筷子。並且醬汁也從京都的比較濃的醬油口味，逐漸變成了甜的口感。 當時日本普燒鰻魚飯的排行（嘉永六年） 天丼的誕生 天丼也就是天婦羅的丼飯，在一開始天婦羅也是單獨吃的。 但是因為在日本橋的天婦羅的吉兵衛，因為他的天婦羅太好吃，旁變得蕎麥麵也變成是一起的爆紅。變成了日本橋周遭的名店，那時候的天婦羅也都是搭著蕎麥麵來一起販賣的。 但是從 1797 年開始，許多的茶泡飯店家都已經有搭著販賣天婦羅。後來受到大舉的歡迎，甚至也有了天婦羅專賣店。裡面在 1874 年也開始有了「天丼」這個名字的產生。那時候的天丼也就是把天婦羅沾了醬汁，或是稍微泡過後放在飯裡面一起端上來。這時候的做法也跟現在的天丼沒有太大的差別。 天丼的菜單 親子丼的誕生 講到親子丼（也就是將雞入與雞蛋放在一起的伴著飯一起吃）的歷史故事更是相當的有趣。日本其實從兩千年前就開始養雞，但是在西元 675 年當時的天武天皇頒發了不准吃牛，馬，狗，猴肉跟雞肉的法律。 所以一開始的時候，日本人養雞是為了他的雞蛋當作營養來源。卻不是為了雞肉本身。幾百年下來，甚至在許多故事裡面都有了吃雞肉會有處罰與破戒的故事產生。 到了江戶時代（西元： 1626 年）左右開始在當時的書籍看到了關於雞肉的料理。但是那時候雞肉還是算是比較下等的禽類食物，甚至是到了江戶時代出現的「親子蔥花面」裡面用的是雁肉加上雞蛋，而不是雞肉。在那蛇後，鴨子，雁子與雞蛋算是上等，而雞肉算是下等（黑人問號）。 到了西元 1854 年由於鎖國開放之後，雞肉的用量開始大增。日本的雞肉養殖業也開始興盛。「親子丼」也是在這個時候出現大約是在1880 年左右。 牛丼的誕生 牛丼在現在算是日本的國民美食，但是就像前面有提到的天武天皇有了禁殺令之後。牛也是不能屠殺的動物之一。也是到了幕末鎖國開放之後，在外國文化的進來改變後，牛肉才變成是日本知名的美食。 一開始也是從牛肉火鍋開始的，江戶時期的後期就有獸肉火鍋。 關東大地震（西元： 1923)年之後，由於日本東京傷亡相當嚴重，甚至各地都有死傷的報告出現。當初許多逃出的人，身上並沒有太多的食物可以做，就將牛肉加上飯來販賣也就是後來牛丼的產生。 豬排飯的誕生 而豬排飯也是跟牛丼有類似的故事，也是從豬肉火鍋變成豬排飯。（當時還是薄薄的一片），後來才加上了透過雞蛋與沾粉去油炸的豬排。這也是豬排飯的產生。 心得: 這一本書相當的有趣，裡面有許多古代文物與當時的菜單與相關的新聞。可以看出作者真的很細心地將相關的丼飯歷史都調查清楚了。 也讓人知道日本的美食是經過哪一些的人文，歷史與相關的時代變遷的結果。 不看這本，真的不會知道以下的相關事項： 丼飯裡面，第一個出現的是鰻魚丼。 天婦羅丼飯，一開始是搭配茶泡飯來販賣的。後來才搭著白飯。 親子丼飯其實一開始都不是使用雞肉，大多是雁肉跟鴨肉，搭配雞蛋。 日本人有很多年其實是不能吃牛肉跟豬肉的。 真的蠻有趣的，推薦大家來看。裡面也有談到相關醬汁的變遷與做法。看了肚子會餓。

前提 平常在準備 LINE Bot 的相關範例程式碼的時候，通常都是沒有加上資料庫。但是有一些的範例程式碼其實有一些儲存資料會比較好。 所以這時候需要加上資料庫的相關讀寫。 當然…. 資料庫也是有窮人版的。由於許多服務都要對於他們的資料庫服務收費之後，這時候就需要有一些變通的方式。 使用記憶體當作資料庫的架設。 那如何讓你在程式碼中，只要寫一次關於資料處理方面，當你的部屬的環境變數有不同，就會使用不同的資料庫來存取呢？ 比如說： 當你有 PostGresSQL 的資料庫 URL ，就使用 PG SQL 相關處理方式。 如果沒有的話，就使用記憶體做為資料庫。 以後也可以增加不同的雲的部署方式。（或是支援 Firebase 相關資料庫) 這一篇文章將開始敘述，如何透過 Golang 的 Interfaces 的方式來達到類似繼承的效果。 使用同一份的程式邏輯程式碼，可以根據你設定的參數不同來讀取不同得資料庫。 範例程式碼 LINE Bot 群組聊天摘要生成器 這次透過上一次的範例文章 [學習文件] LINE Bot 群組聊天摘要生成器 作為一個範例程式碼。 先來看整體切割方式。 Github Repo: https://github.com/kkdai/LINE-Bot-ChatSummarizer ## 資料架構切割圖 所有的 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) 未來發展 透過 Interfaces 來當作資料庫存取的開發方式可以很方便，並且留下未來許多資料庫的資源空間。不論是支援 MongoDB 或是想要使用 MySQL 甚至是整個資料庫搬到 FireStore 也不需要改動我原版的商業邏輯部分。 只需要把基本的資料庫實作完成即可。 希望這篇文章可以給大家一些想法。