每個應用程式都需要管理狀態。在React中，我們可以使用hooks，尤其是useState()，並傳遞props來解決許多問題。 當事情變得比較複雜時，我喜歡立即轉向使用狀態管理庫。最近我最喜歡的之一是easy-peasy。 它基於Redux構建，並提供了一種更簡單的方式來與狀態交互。 我喜歡保持我的程式碼盡可能簡單。簡單易懂，簡單美觀。 應該盡量避免複雜性，並將其隱藏在向我們提供簡單接口的庫中。這就是這個庫的情況，也是我喜歡它的原因！ 使用以下命令進行安裝： npm install easy-peasy 首先，我們需要創建一個store（存儲庫）。存儲庫是存儲我們的狀態和修改狀態所需的函數的地方。 在專案的根目錄中的store.js文件中創建存儲庫，內容如下： store.js import { createStore, action } from 'easy-peasy' export default createStore({}) 我們稍後會在這個文件中添加更多東西。 現在，將React應用程序包裝到easy-peasy提供的StoreProvider組件中。這取決於您使用的工具。例如，在create-react-app中，將以下代碼添加到您的index.js文件中： //... import { StoreProvider } from 'easy-peasy' import store from '../store' ReactDOM.render( <React.StrictMode> <StoreProvider store={store}> <App /> </StoreProvider> </React.StrictMode>, document.getElementById('root') ) 這個操作使我們的存儲庫在應用程序的每個組件中都可用。 現在你可以在store.js文件中添加一些狀態和一些用於改變該狀態的操作。 讓我們進行一個簡單的例子。我們可以創建一個name狀態，並創建一個setName操作來改變名字： import { createStore, action } from 'easy-peasy' export default createStore({ name: '', setName: action((state, payload) => { state.name = payload }) }) 現在，您可以在應用程序的任何組件中從easy-peasy導入useStoreState和useStoreActions：...

在開發網頁時，您可能會見到類似以下的鏈接： <a href="#">功能</a> 這裡的 href="#" 是一個佔位符。該鏈接不會指向任何特定的地方。 有時這表示應用程序正在進行中，我們稍後會填寫該鏈接的 href 屬性。 其他情況下，您可能會見到以下類似的鏈接： <a href="#features">功能</a> 這種情況下，該鏈接引用了同一頁面中的某一點。 您會在頁面中找到類似以下元素： <a id="features">功能</a> 這個元素也可以是一個空元素，它存在於頁面上，但是被隱藏起來： <a id="features"></a> 請注意，我們在這裡使用了 id。 點擊這個項目： <a href="#features">功能</a> 將會跳轉到 id 等於 features 的 <a> 標簽。 完整描述一下，如果鏈接是這樣的： <a href="/features">功能</a> 點擊時，瀏覽器將在一個單獨的 URL 上打開。 您還可以結合使用，比如： <a href="/features#first">功能</a> 將打開 /features 的 URL，並滾動到 id="first" 的 <a> 標簽。

過去幾週，我一直在認真學習SwiftUI。 再次嘗試之前，我曾經嘗試過，但只堅持了幾天。 它和React非常相似，除了語言不同，SwiftUI使用的是Swift而不是JavaScript。 當然，這並不是什麼新鮮事。SwiftUI無疑受React和React Native的啟發。我只是作為一位資深的React開發者對其印象做個表述。 React在Web上引入了一些徹底改變我們構建應用程序方式的事物: 声明式UI、不可變性和基於數據的UI更改。 這些都是具有改變思維方式的概念，也是Apple平台(如iOS、macOS、iPadOS、watchOS)的一個徹底變革。 當Apple在2014年引入Swift時，他們做出了一個明智的選擇，即與我們使用Objective-C的現有框架UIKit和AppKit進行無縫集成。 由於這個原因，Swift在早期階段就獲得了廣泛的應用，因為開發者對這些框架的工作方式已經非常熟悉，只不過語言發生了變化。 5年過去了，Apple的所有開發者都有足夠的時間用Swift來開發新的應用程序，這使得SwiftUI(於2019年推出)成為了一個徹底的變革。 我敢說，它甚至比Swift本身的引入更加徹底。 現在距離SwiftUI首次推出已經過去了2年。 除非你是早期採用者，否則在跳入"新熱門"之前，你應該等待一段時間以改善問題。 一開始，只有錯誤和沒有文檔，第三方庫的支援也很差。 現在SwiftUI已經成熟到足夠的程度，每個Swift教程也可以算是SwiftUI教程，而Apple也正在不斷努力使其更加優越。 我對Playground應用程序特別感興趣，因為它可以直接從iPad上構建SwiftUI應用程序。 我認為這是一種非常好的構建軟件的方式，但目前尚不可用。我們只是在WWDC上得到了一個潛在的預覽。 特別適合簡單的軟件開發，特別是初學者在學習編程時所寫的軟件。

在使用關聯模型時，我們有兩組可以使用的操作。其中之一是關聯代數。 在使用關聯模型時，我們有兩組可以使用的操作。 第一組被稱為關聯代數，它是一種程序性語言。 這是SQL的基礎，因此學習它非常重要 - 因為SQL是處理關聯式數據庫的事實標準。 第二組被稱為關聯演算，與程序性不同，它是一種聲明性語言。這是我們與數據庫進行交互的一個基本差異，因為你不告訴數據庫軟件要做什麼，你只告訴它你想要什麼，然後讓它處理如何實現。 在編程語言中，這是一個常見的區別。在現代前端開發中，我們說在React中與DOM的交互是聲明式的。使用原始的JavaScript修改DOM是程序性的。 數據日誌、QBE和QUEL等語言以關聯演算作為基礎。我不打算談論它，因為我認為這是一種比SQL更專門的做事方式，但如果你有興趣，你可以看看它。 在簡介結束後，讓我們繼續講解關聯代數。 我們有兩種類型的操作： 基本操作 連接操作 關聯代數的基本操作 基本操作包括： 聯集：從兩個表中獲取數據，生成元組的和，前提是兩個表具有相同的列和屬性類型（域）。 差異：獲取包含在第一個表中但不在第二個表中的數據，生成元組的差異，前提是兩個表具有相同的列和屬性類型（域）。 笛卡爾積：從兩個表中獲取數據，並生成一個結合它們數據的單個表，基於屬性值。 選擇：根據某些條件僅提取表中的某些元組（行）。 投影：生成一個新表，只包含現有表的一個或多個屬性（列）。 重命名：用於重命名屬性，防止在不同數據中有相同名稱的多個表發生衝突。 關聯代數的連接操作 連接可能是你可以使用關聯代數進行的最強大的操作。它們建立在基本操作之上，允許你關聯不同關係（表）中包含的數據。 注意：我很快就會談到在數據庫管理系統中實際應用連接，這主要是理論上的介紹。 我們有兩種主要的連接版本：自然連接和θ連接。所有其他版本都是從這兩個版本中提取出來的。 自然連接 自然連接將兩個關係（表）進行關聯，並基於屬性的相同值創建一個新表。 首先，我們需要兩個具有相同屬性名稱（列）的關係。然後，如果關係A中的屬性值在關係B中的屬性中沒有相應的匹配值，該行不包含在結果中，它被忽略掉。 例如： 關係A： 員工編號 姓名 1 Mark 2 Tony 3 Rick 關係B： 經理姓名 員工編號 Todd 1 Albert 2 我們可以通過自然連接獲取每個員工的老闆姓名： 員工編號 姓名 經理姓名 1 Mark Todd 2 Tony Albert 由於關係中有相同的員工編號屬性名稱，結果中只出現一次，而不是兩次。 在關係A中出現的員工編號3，Rick，不包含在這個表中，因為在關係B中沒有相應的記錄。 θ-連接 Θ-連接允許根據任何條件比較兩個不同關係中的兩個列進行連接，而不僅僅是像自然連接那樣進行相等的比較。 它對兩個表執行笛卡爾積，並根據我們想要進行的選擇來過濾結果。 等值連接 等值連接是一種θ連接，其中的選擇是基於兩個不同表中屬性值的相等。 與自然連接的區別在於，我們可以選擇要比較的屬性名稱（列）。 稍後在介紹SQL時，我們將更詳細地討論連接，以便在實際應用中使用它們。

關聯型資料庫是關聯模型理論所表達的概念的軟體實現。 在關聯型資料庫中，資料以 表格 的形式儲存。 每個表格包含一個或多個 欄位，用於存儲特定 類型 的資料，例如字串、數字等。 表格及其欄位的一組規則被稱為 模式。 每個表格都可以對每個行所包含的資料設定 限制。 表格可以相互引用，形成關聯，使用 外鍵。 資料庫管理系統是在電腦系統中實現資料庫的軟體。 通常，關聯型資料庫使用 SQL 語言 讓我們能夠創建資料庫、定義其表格模式、填充資料庫中的資料，並在需要時查詢資料。 一些實現關聯型資料庫的軟體包括 PostgreSQL、MySQL、SQLite、Oracle 和 Microsoft SQL Server。

關聯模型是在資料模型帖子中列出的邏輯資料模型中最受歡迎的，並且它是基於SQL資料庫的基礎。 關聯模型基於兩個簡單的概念： 表格 關聯 關聯模型可以追溯到1969年，當時英國計算機科學家Edgar F. Codd提出了這一概念。作為計算機程序員，我們習慣於關注新奇的事物，但一個能夠在計算機領域中持續50年的技術絕對值得學習。 模型基於表格的事實使其非常直觀易用，因為我們習慣於使用表格來組織事物。比如，想想Excel電子表格。 使用像PostgreSQL、Oracle、MySQL、SQLite和MS SQL Server等基於SQL的資料庫，可以使用關聯模型對使用ER模型分析的數據進行建模，並且幾乎可以立即將其轉換為SQL資料庫格式，這可以被視為關聯模型在現實世界中的實現，但我們將在其他帖子中討論這一點。 在這篇帖子中，我想探討的是關聯模型基於的理論和概念，不是用數學术语表達，而是在實踐中的含義。 如果你是一個學生，你可能會發現我在這裡寫的內容與你的教科書上的內容不一樣，但也許你可以通過閱讀這種更容易理解的方式來掌握在你的學習材料中表達的更正式的概念。 表格 在關聯模型中，表格是一組項目的集合。 它按行和列組織： 名稱 年齡 Flavio 36 Roger 7 Syd 6 元組 表中的每個項目稱為元組。您也可以使用記錄或行這些術語。 元組表示表的一行，如下所示： Flavio 36 屬性 屬性是元組中的一個單一項目。 在這個例子中： Flavio 36 “Flavio”是一個屬性。 36是另一個屬性。 元組是唯一的 表中的每個元組都是唯一的。 在關聯模型中，我們不能有重複的數據，這意味著表中的每一行在至少一個屬性上必須不同。 關聯鍵 確保元組唯一性的是關聯鍵。 關鍵是必須唯一識別元組的一個屬性。 如果關聯鍵是一組屬性，它必須是非冗餘的。這意味著如果我們刪除鍵的其中一個屬性，該鍵將無法確保其唯一性。 如果可以確定多於一個鍵，其中一個鍵將被識別為主鍵。 關鍵完整性約束 表中的任何元組的關鍵屬性不能為null，並且不能重複。 根據一個鍵，我們必須能夠指向一個特定的元組/行，而不會產生歧義。 域限制條件 每個屬性都有關於它可以包含的值的規則。 例如，如果我們決定存儲數字，就不能存儲字符串。我們還可能決定不存儲長於10個字符的字符串作為名稱。 我們也可以稱之為類型。 參考完整性約束 如果一個表包含對一個次要表或同一表中的其他元組的引用，那麼我們必須遵守規則，以防止引用的破壞。 特別是，我們必須避免以下情況破壞引用： 在其他表中，避免刪除或編輯我們指向的記錄的主鍵。 避免插入指向其他表中不存在的鍵的新記錄。 避免改變我們指向的記錄的鍵，而不確保新鍵存在於其他表中。 數據庫管理系統（DBMS）將實施措施來幫助我們實現參考完整性。

了解什麼是類型化數組以及如何使用它們 JavaScript提供了8種類型化數組類型： Int8Array：8位有符號整數數組 Int16Array：16位有符號整數數組 Int32Array：32位有符號整數數組 Uint8Array：8位無符號整數數組 Uint16Array：16位無符號整數數組 Uint32Array：32位無符號整數數組 Float32Array：32位浮點數數組 Float64Array：64位浮點數數組 它們都是ArrayBufferView實例。 類型化數組本質上是對ArrayBuffer的一個視圖，其中每個項目的大小和類型相同。 DataView是對ArrayBuffer的另一種視圖，但在這種情況下，數組中的項目可以具有不同的大小和類型。 以下是創建一個8位有符號整數數組的示例： const a = new Int8Array() 您可以預先分配n個字節： const bytes = 1024 const a = new Int8Array(bytes) 主要用途是允許查看ArrayBuffer的內容，因為ArrayBuffer本身是不透明的（我們無法查看其內容）。 下面是如何進行查看： //我們有這個`buffer` ArrayBuffer const a = new Int8Array(buffer) 這些類型化數組類似於數組，因此現在我們可以通過常用的數組訪問技術來查看緩衝區的內容，並且我們可以訪問許多方法和屬性，包括map()、reduce()等。 類型化數組的主要用例是與WebGL、Web Audio或Canvas API一起使用。一些WebGL函數期望使用類型化數組，因為它們比常規JavaScript數組更高效。 需要記住的一點是，類型化數組無法控制字節順序：它使用平台的字節順序。一般來說，這樣做是沒問題的，因為正如我們所說，主要用例是在本地使用數組，使用多媒體API之一。另外，大多數消費型計算機使用小端序（Intel使用該約定）。但是，如果您將類型化數組的數據轉移到使用大端序的系統上，則數據可能編碼錯誤，因此無效。 如果需要對字節順序進行這種控制，請改用DataView。

如何在您的網站上嵌入YouTube視頻並使其具有響應式，在移動設備上能適應縮小顯示。 嵌入YouTube視頻的問題在於它們是iframe，並且iframe需要給定確切的高度和寬度，否則它們將顯示不正常。 而且，我們需要保持按比例，根據視頻的寬高比。 要在您的頁面中顯示一個響應式的YouTube視頻，首先將它包裝到一個容器div中： <div class="video-container"> <iframe src="https://www.youtube.com/embed/...." frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </div> 然後在您的網站中添加以下CSS： .video-container { overflow: hidden; position: relative; width:100%; } .video-container::after { padding-top: 56.25%; display: block; content: ''; } .video-container iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; } 看到那個魔法數字，56.25%了嗎？這是當視頻的寬高比是16:9時需要的填充比例。（9是16的56.25%） 如果您的視頻是4:3的，請將其設置為75%。

在我的一些電子教程中，我通常會將電路連接到一個9V電池，因為這是非常簡單且容易找到的。 但這並不是最佳的解決方案。首先，電池會隨著時間的推移而耗盡，無法提供所宣稱的9V電壓。 麵包板電源模組通過從電池、12V適配器或其他任何電源的“桶型插孔”輸入，根據我們的需求為電路提供5V或3.3V電壓。我們將很快引入Arduino系列開發板到我們的電路中，而所有的Arduino電路都將使用這些電壓。 有很多不同的模組可供選擇，這是我想要向你展示的電源模組，它是Elegoo套件的一部分，我建議你去購買，但也有其他品牌販售相同形狀和特性的產品，你可以在亞馬遜上搜索“Arduino電源”來看看其他選擇： ！ ！ ！ ！ ！ 輸入電壓範圍為6.5V至9V直流電。 最大輸出電流為700mA。 我們可以直接將其連接到麵包板上： ！ ！ ！ 然後，你可以在每側選擇要應用到麵包板上的電壓，可以獨立選擇5V，例如這種情況： ！ 或者3.3V，通過更改跳線的位置： ！ 你也可以將其關閉，將跳線放置在中間位置： ！ 然後，你可以使用桶型插孔連接到12V至220V適配器： ！ 按下灰色按鈕開啟它，LED燈將會亮起： ！ ！ USB端口並不是用來為電源模組供電的，它用於根據需要供電給USB設備（例如Arduino）。 麵包板上還有其他提供GND、5V和3.3V的輸出接口，以防需要使用： ！

我喜歡冬天。冬天充滿了挑戰。 在露營車上旅行，當然很有趣，但當天氣變冷時就不同了。如果你計劃只在夏天使用你的露營車，那就沒有太多需要了解的。 隨著冬天的到來，會有不同的需求出現。 注意：我要談談低於攝氏-30度/華氏-22度的寒冷， 这在瑞典和意大利阿爾卑斯山附近（我住的地方）都有經歷過（是的，義大利的某些地方也會這麼冷）。我對更低的溫度沒有經驗。 首先需要注意的是，你需要一個加熱系統。我的露營車裡有兩個。最初它是配備的一個Truma Combi 4 LPG加熱爐。這個4千瓦加熱爐很棒，但它需要使用液化石油氣（LPG）。 LPG有點麻煩。如果用於加熱，每4到5天就可能消耗一個10升的LPG罐，取決於天氣多冷。 獲取LPG相對困難，特別是在國外。在歐洲，國外的瓦斯罐可能擁有不同的插頭。即使有地方可以獲得新的瓦斯罐，也令人困擾，因為你不再自由自在。你需要隨時攜帶兩個瓦斯罐，以免在晚上用完一個（有一次我就碰到這情況）。 因此我安裝了一個柴油加熱器，Eberspächer Airtronic D2，一個2千瓦的柴油加熱器。它非常小巧，但在攝氏零下20度以下時效果更好。 這個柴油加熱器非常方便。我不需要擔心。我可以在開車時打開它（我對開車時開放LPG有一些顧慮，雖然有一些工具可以讓你這麼做，比如Truma SecuMotion）。 最重要的是，擁有兩個系統非常安全。一個系統出故障了，還有另一個。在寒冷的氣溫下，這種冗余非常重要。有一次，和我在同一個地方的另一個人的Truma柴油加熱器由於柴油無法完全適應寒冷（取決於您在哪裡加油）而失效。那天外面溫度達到攝氏零下28度，你可以想象那是多麼糟糕。 在冬季，隔熱非常重要。夏季隔熱也很重要，但冬季更加重要。隔熱很大程度上取決於供應商。在大多數露營車中，隔熱是不存在的。我建議你花時間將板塊隔熱化，至少在你可以接觸到的地方隔熱化。細節至關重要。 此外，你可以在前擋風玻璃上放一個外部保護蓋。 如果溫度只下降到攝氏零下10度，你不需要太擔心。如果你瘋狂到喜歡在攝氏零下20度露營，問題就開始浮出水面了。 這些是露營車廠家不會告訴你的問題，當然了。最嚴重的一個問題就是水。水很好，但是它有這個特性，在攝氏0度以下會變成冰。 冰有膨脹的趨勢。冰凍成冰的管道將損壞管道和所有連接器。 看來我在冬天遇到了水的問題。我確實遇到了。 似乎露營車（但也包括房車）生產商對冬季不了解。他們假設我們都只在晴天和炎熱的天氣中使用我們的車輛。 你首先會遇到的問題是，如果水箱在車外，灰水可能無法排出。應該打開的閥門不會動，因為凍結了。這种情況非常常見。絕對不能強行調用，只需等待天氣變熱。如果天氣不會轉暖，你有兩個選擇。 一個是使用加熱槍，小心使用。如果有230V的電力可用，這很有用。 更大的問題是水箱內的水結冰。你需要給灰水箱隔熱。當然，你在購買露營車之前必須考慮到這一點。或者自己對其進行隔熱。但隔熱是毫無用處的，除非在箱內有供暖源。 我選擇最簡單的方式，安裝一個電阻，這是大多數製造商提供的“冬季套件”時所做的。它基本上毫無用處，因為它是12V供應，所以除非你不連接到230V，否則它的功率非常小。理想的解決方案是將加熱管通過儲水箱。這將非常有幫助，這是我未來計劃的一部分。 水不僅可能在水箱內結冰，也可能在通向水箱的管道內結冰。 這種情況發生在90度彎曲處。一點點水會停滯在那裡，並凍結成冰。隨著時間的推移，所有的地方都會結冰，管道中充滿水，以至於你無法排出水槽裡的水。我就遇到過這種情況。這裡唯一的解決辦法就是等待，並希望管道沒有損壞。 我遇到了足夠多的這些問題，所以當天氣變得非常冷時，我使用了一個替代系統。我有兩個較小的便攜式水箱，需要時可以將其排空。我只需將管道連接在水槽排氣孔下面，當水箱滿了時，我將其倒在露營區的浴室內（把肥皂倒在大自然中是不好的，對吧）。 99%的人永遠不會遇到這個問題。我只是提到這點，如果你喜歡滑雪或在攝氏零下30度的天氣中遊玩。我有两只哈士奇，它们喜歡冷天氣，我也一样。 現在讓我們談談露營車內的水管。有些製造商把它們安裝在最瘋狂的地方。我改變了我露營車內的水管位置，因為它們總是結冰。即使車內溫度達攝氏20度，當室外溫度達攝氏零下15度時，我仍然無法在浴室水槽中取得水，因為水管距離車外金屬太近了。我試過隔熱，但沒有改變。中有冷的水在管道內仍然會凍結。 通常情況如下：製造商將水管放在加熱系統旁邊。不是所有的都這樣，但大多數都是這樣。 我的露營車從工廠出來時配備了一個LPG加熱器，就是之前提到的Truma Combi 4。有些管道跟隨了Truma加熱系統的布局，有些則沒有。這台車就是不為冬天而建造的。 所以當我安裝了輔助的Eberspacher柴油加熱器後，我確保了水管遵循它的加熱管線。問題解決了。 幾乎是。 因為大多數露營車都有所謂的“防凍閥”，當車內開始變得太冷時，它会把水排放到外面。 我在第一次旅行中發現了這一點。那時正值冬天。我在家裡加滿了清水。到達目的地後，過了6個小時，水就沒了。它自動排出了，非常緩慢地在路上排放水（清水！），因為防凍閥認為“嗯，它開始變冷了！”而“變冷”指的是攝氏5度。 這是系統的明顯設計失誤。這個閥門本來應該保護鍋爐——這是一個價值2500歐元以上的組件，它是對的。但由於某種我不知道如何命名的水力原理，它還會排空水箱。 隨著時間的推移，我通過添加一個手動閥門來解決這個問題，以排除系統中的鍋爐，如果我不想使用它的話，我就摘除了這個自動閥門。不再漏水了！ 另一件你很快就會發現的事情是，熱往上走。你的頭很熱，你的腳很冷。 通常所有的管道都會放在暖氣無法直接加熱的隱藏式位置。為了解決這個問題，我把所有的管道放得盡可能高（不靠近底部），還刪除了妨礙熱量傳播的面板。這樣做可能不美觀，但它起作用。 冬天的另一個挑戰是使鞋子乾燥。你的鞋子可能被雪或水弄濕，你可以把鞋子放在有加熱風門的地方，或者你可以購買專為這個特殊目的而製作的電熱裝置。我有一個350瓦的裝置，有4根管子，所以你可以烘乾2雙鞋。 至此，這就是冷天的經驗。 如果你打算在寒冷氣候中花很多時間，你還可以投資一個引擎加熱器，如Webasto Thermotop。這將確保引擎能夠無問題地啟動，並保持正確的水溫。這是我未來計劃的一項工作，但這個計劃已經拖了很多年，不確定我是否會實現它。