雅克，偶爾寫點東西紀錄

1.下載並安裝DBeaver或是其他MySQL的IDE都可以(這邊範例使用DBeaver) DBeaver Download 此為免安裝版，下載下來解壓縮後，執行DBeaber.exe就可以開啟了 有需要使用中文介面的話(僅有簡體)，則是在開啟的時候加上 -nl zh   2.開啟之後，點擊左上角的插頭，選擇資料庫用MySQL，然後next   3. 然後輸入自己的MySQL資料庫訊息。 4. 輸入完畢之後，左下角可以測試連線是否正確。 P.S. 此時如果沒有安裝MySQL驅動的話，程式會詢問是否安裝，放心安裝就可以囉。 5. 在Windows->Preference->General->Appearance->Color and Fonts中 Basic可以設定編輯器的文字大小 以上為DBeaver的安裝及簡單的設定 設定完畢之後，左邊會資料庫會多了剛剛所設定的資料庫 第一層展開後會有 Databases(資料庫)、Users(使用者)、Administer(管理員)、System Info(系統資訊)的資料夾。 這邊我們只會使用到Database(資料庫)，其他暫時先不去看。 MySQL中一個主機可以有多個資料庫，Heroku app建立後預設會建立一個 這邊以該資料庫做為範例。 一個資料庫中會有 Tables：資料表，主要存放存進資料庫中的資料。 Views：檢視表，主要為查詢指令的結果集。組合成可查詢的資料表的一種資料庫物件 Index：索引，為一種與資料表或檢視有關的磁碟內存結構，會加快從該資料表或檢視中擷取資料列的速度 Procedures：預存程序，簡單來說就是用SQL語法寫的程式。 Triggers：觸發程序，為回應DDL(資料定義語言)使用會執行的程式。當有使用者使用DDL的時候會執行的程式。 Events：延伸事件，恩！這我不太會解釋，之後我詳細學完再回來寫。不過這次用不到 接下來看到右邊的文字輸入區域。如果沒有地方輸入的話，按下F3，然後按New Script會出現 首先簡單介紹一下SQL的幾個語法 1.Data Definition Language：簡稱DDL，資料庫定義語言。為定義資料庫結構所使用。 簡單分為CREATE/ALTER/DROP等等，使用者權限過高不會使用的話，建議不要輸入...

安裝Python 選擇Customize installation   確認pip有被打勾，下一步   記得將python加入系統變數中，不然cmd中無法使用。 Visual Studio Code VSCode中也需安裝python套件 Python 以下指令如果發現VSCode沒辦法輸入的話，關掉VSCode重開試試看。 安裝discord.py 指令：pip install discord.py 安裝request 指令： pip install requests 安裝emoji(多群組顯示emoji做表示使用) 指令：pip install emoji Discord Bot設定 此部分如果在進行修改/刪除時有出現權限問題錯誤時再進行調整 如果Bot沒有管理者權限的話，在交流用頻道內設定Bot可以管理訊息即可。

第一次上版 heroku login git init heroku git:remote -a <app_name> git add . git commit -am "make it better" git push heroku master 以上執行完畢後回到Heroku App畫面 在Resources的地方將web npm start關閉 Protfile中的worker打開 後續更版 heroku login git add . git commit -am "make it better" git push heroku master  

PRIMARY Key(PK) (主鍵) 是一種 index 但不能為空值(NULL)，PK 會自動建立 index 每個 table 只能有一個 PRIMARY Key 語法為 CREATETABLE tablename ( […], PRIMARY KEY (列的列表) ); 在 Rails 裡面，默認 id 為 primary key Index (索引鍵) 資料索引，可加快搜尋速度，Mysql 引擎除了 Archive 外都支援 B-tree 索引 可多欄位設定為 Index 語法為 CREATE INDEX <索引的名字> ON tablename (列的列表) Unique (不重複鍵) 和 index 相同，差異在於不能允許重複值 語法為 CREATE UNIQUE INDEX <索引的名字> ON tablename (列的列表) Index 的觀念 index建立會占用儲存空間，資料增刪修時會異動 index 欄位長度是越短越好 index 欄位長度若是固定比變動好 使用「LIKE」參數時，若將萬用字元（%）置於關鍵詞後方，可以使用到 index，前方不起作用 單列索引與多列索引的觀念： 將「A＋B＋C」設為 index 時，僅搜尋A是不會用到索引的 「A＋B＋C」和「A」設為 index不同，如搜尋A＋B＋C，前者直接回覆A+B+C索引值，後者為A用索引，縮小範圍後再以搜尋B＋C 來源： [喜歡在地上滾的工程師]-[SQL 基本觀念]

  最近加了不少群組，也看到有些群組在使用webHook進行跨伺服器聊天，所以才有感而發地想寫一下跟測試一下處理流程到底是怎麼進行的。 (但說實在的我也不知道我測出來的理解對不對) 首先是簡單的點對點，一般理解下的運作是像下圖 使用者1在A群組頻道中發文，傳給discordBot，轉交給B群組的webHook進行發文。反之亦然。 可是當兩個頻道間訊息過度頻繁，抑或是A群組頻道過度頻繁發話，會造成訊息無法傳至另一端的狀況，但此情形過一段時間即會解決，中間漏傳的也會隨之補上。 此情境發生的原因應是WebHook的cache堆積，或是過度頻繁傳送訊息，導致伺服器端認為被DDoS攻擊之類的。但如果假設我們在設定的ClientOptions是給WebHook的，而不是給Discord Bot的呢？以下是我以上圖為例思考的分流傳送方式。 以一開始我的預想，這樣進行分流的話兩個WebHook的負擔應該會分擔處理，也可以發送更多的訊息而不會出現cacheMemory溢出的狀況。 因為我只有一個人，也沒辦法測試多人發話的狀況，所以以下是我寫的SourceCode，用迴圈跟TimeOut的方式輪流跑兩個webHook。 結果大概跑到第30則訊息的時候就卡住了....這什麼狀況？回頭看DiscordServer想重新建立WebHook重跑，結果出現 然後我就有疑問了，既然我們在 new Discord.WebhookClient 的時候可以設定 ClientOptions ，那為什麼這邊兩個有分別設定了，可是跑的訊息數卻跟單個WebHook時一模一樣？ 還是說這邊設定的 ClientOptions 不是給WebHook的而是給server的？那稍微調整一下的話呢？ 測試完畢後發送訊息數有增加了，但還是會卡住，已經設定是最低了還是會造成訊息卡住的問題，看來是無法使用分流的方式來解決問題了。 於是我轉念一想，多開幾個機器人處理看看呢？ 然後發不到五個訊息，兩邊的WebHook就都掛了，真棒。