🔍 搜尋結果:transaction

🔍 搜尋結果:transaction

您需要了解的有關軟體要求的訊息

想像一下,您的客戶要求您建立一個 Web 應用程式,以滿足其客戶的所有需求。這就是你的客戶會告訴你的全部內容,你能建造它嗎?很明顯,您錯過了更多訊息,並且存在要求,但您知道什麼是要求嗎?如果我們沒有明確定義它們,會產生什麼後果?存在哪些類型的需求?本文將嘗試以簡單的方式回答其中一些問題。 概括 -- - [什麼是要求?](#what-is-a-requirement) - [為什麼它們很重要以及需求定義不明確的後果](#why-they-matters-and-consequence-of-poorly-defined-requirements) - [我們怎樣才能有一個好的需求](#how-we-can-have-a-good-requirement) - [要求等級](#levels-of-requirements) ``` - [User requirements](#user-requirements) ``` ``` - [System requirements](#system-requirements) ``` - [要求類型](#types-of-requirements) ``` - [Functional requirements](#functional-requirements) ``` ``` - [Non-functional requirements](#non-functional-requirements) ``` - [結論](#conclusion) 什麼是要求? ------ 首先,我們需要了解軟體開發環境中的需求是什麼。 Shari Pleeger 給我們下了一個很好的定義: > 系統特徵或系統為實現其目標而能夠完成的事情的描述 換句話說,要求是辨識產品或流程操作、功能或設計約束或特徵的聲明,該聲明是**明確的**、**可**測試的、**可測量**的,並且是接受產品或流程所必需的(由消費者或內部品質保證指南) 。 每個需求都是基於現實中存在的問題而建立的,而軟體只是解決它的一種方法。 為什麼它們很重要以及需求定義不明確的後果 -------------------- 現在我們知道什麼是要求,我們必須問: > “為什麼對於從事 IT 工作的人來說了解它如此重要?” 我會給你一些原因。根據要求,我們能夠: - 為專案規劃提供依據 - 對於研究變更請求至關重要 - 允許從開發的最早階段進行風險管理 - 它們是驗收測試的基礎 - 合約管理 ![圖片1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x13z95rmek1u9g1bhnu4.png) 如果我們的需求定義不明確會發生什麼事? 第一個也是合乎邏輯的後果是專案交付的延遲。當我們開始一個專案或衝刺時,沒有對要開發的內容有所有明確的要求,存在錯誤的可能性是巨大的!因此,開發人員和 QA 團隊需要承擔更多工作,從而降低了他們的生活品質。 如果出現在Production中,就會有許多不滿意的用戶,讓產品的信心降低,甚至導致系統報廢。另一個後果是維護系統的成本。 我們怎樣才能有一個好的需求 ------------- 需求的編寫方式因團隊而異,但它們都應該具有以下三個特徵: - 明確 - 可測試 - 可測量的 要求等級 ---- ### 用戶要求 使用者需求定義了我們的軟體需要做什麼。它可以透過使用者的需求、期望、限制和介面來描述使用者面臨的問題。 此類需求是為客戶編寫的,我們使用自然語言加圖表。我們可以使用待辦事項清單應用程式的使用者需求範例: > 使用者應該能夠在清單中插入新任務 ### 系統需求 系統需求是定義系統有效運作所需的硬體、軟體和網路元件的功能和約束的規格。 這些要求對於設計、實施和維護系統至關重要。他們負責描述必須做什麼,而不是如何做。 使用我們已經使用過的相同要求,我們可以詳細了解它: |用戶需求|系統需求 | | -------------------------------------------------- ------ | -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ------------------------------------------ | |使用者應該能夠在清單中插入新任務 | - 使用者應該能夠點擊插入按鈕以新增任務 \- 當使用者點擊按鈕時,任務新增應出現在清單中 插入 \- 只有登入使用者才能存取任務清單| 要求類型 ---- ### 功能要求 功能需求描述了一個系統應該執行的操作。它們描述了系統應該提供什麼、系統應該如何對特定輸入做出反應以及系統在特定情況下應該如何表現。他們還可以描述系統不應該做什麼。 功能需求可以描述使用者或系統需求。 ### 非功能性需求 非功能性需求描述系統或環境應提供的服務或功能。他們負責定義系統的架構。我們對非功能性需求有不同的類別,它們是: 1. **表現:** ``` - _Response Time:_ Specifies the maximum acceptable time for the system to respond to user input. ``` ``` - _Throughput:_ Defines the number of transactions or operations the system can handle in a given time. ``` 2. **可用性:** ``` - _User Interface (UI) and User Experience (UX):_ Specifies criteria related to the design, ease of use, and overall user experience. ``` ``` - _Accessibility:_ Ensures that the system is usable by individuals with disabilities. ``` 3. **可靠性:** ``` - _Availability:_ Specifies the percentage of time the system should be operational. ``` ``` - _Fault Tolerance:_ Defines the system's ability to continue functioning in the presence of faults or errors. ``` 4. **安全:** ``` - _Authentication:_ Describes how users are identified and verified. ``` ``` - _Authorization:_ Specifies the level of access granted to different users or roles. ``` ``` - _Data Encryption:_ Requires the use of encryption to protect sensitive data. ``` 5. **可擴充性:** ``` - _Horizontal Scalability:_ Describes how well the system can handle an increase in load by adding more hardware. ``` ``` - _Vertical Scalability:_ Describes how well the system can handle an increase in load by increasing the capacity of existing hardware. ``` 6. **相容性:** ``` - _Hardware Compatibility:_ Ensures the system can run on specified hardware configurations. ``` ``` - _Software Compatibility:_ Ensures the system can work with specified software components. ``` 7. **可維護性:** ``` - _Modifiability:_ Describes the ease with which the system can be modified or updated. ``` ``` - _Testability:_ Specifies the ease with which the system can be tested to ensure its correctness. ``` 8. **可移植性:** ``` - _Platform Independence:_ Describes the ability of the system to run on different operating systems. ``` ``` - _Data Portability:_ Ensures that data can be easily transferred between different systems. ``` 9. **文件:** ``` - _User Documentation:_ Specifies the requirements for user manuals and guides. ``` ``` - _Technical Documentation:_ Describes the requirements for system architecture, API documentation, etc. ``` 10. **監理與合規:** ``` - _Legal Requirements:_ Ensures that the system complies with relevant laws and regulations. ``` ``` - _Industry Standards:_ Specifies adherence to industry-specific standards. ``` 結論 -- 正如我們所看到的,軟體需求對我們來說非常重要,並且有很多不同類型的需求,但最重要的是確保在開始開發之前,我們已經很好地定義了它們。 我希望這些內容對您有用。 如果您有任何疑問,請隨時與我聯繫! 親吻💅🏼 --- 原文出處:https://dev.to/m4rri4nne/what-you-need-to-know-about-software-requirements-2hc0

JSON 效能比較慢。這邊介紹 4 個更快的替代方案

原文出處:https://dev.to/nikl/json-is-slower-here-are-its-4-faster-alternatives-2g30 --- ## 介紹 在快節奏的 Web 開發世界中,速度和反應能力是不容妥協的。您的用戶希望即時存取資訊、快速互動和無縫體驗。 JSON 是 JavaScript 物件表示法的縮寫,一直是 Web 開發中資料交換的忠實夥伴,但它會減慢您的應用程式速度嗎?讓我們深入探討 JSON 的世界,探索其潛在瓶頸,並發現更快的替代方案和優化技術,讓您的應用程式像獵豹一樣衝刺。 --- 您可能還想查看本教學:[使用 Golang 建立即時通知系統 - 逐步通知系統設計指南](https://dev.to/nikl/using-golang-to-build -即時通知系統逐步通知系統設計指南-50l7) --- ### 什麼是 JSON 以及為什麼您應該關心? 在開始 JSON 優化之旅之前,讓我們先了解 JSON 是什麼以及它為何重要。 JSON 是將應用程式中的資料黏合在一起的黏合劑。它是伺服器和客戶端之間通訊資料的語言,也是資料儲存在資料庫和設定檔中的格式。從本質上講,JSON 在現代 Web 開發中發揮關鍵作用。 了解 JSON 及其細微差別不僅是任何 Web 開發人員的基本技能,而且對於優化應用程式也至關重要。隨著我們深入研究此博客,您將發現為什麼 JSON 在性能方面可以成為一把雙刃劍,以及這些知識如何對您的開發之旅產生重大影響。 ## JSON 的受歡迎程度以及人們使用它的原因 JSON 在 Web 開發領域的受歡迎程度怎麼強調都不為過。由於以下幾個令人信服的原因,它已成為資料交換的事實上的標準: 1. **人類可讀格式**:JSON 使用簡單的、基於文字的結構,開發人員和非開發人員都可以輕鬆閱讀和理解。這種人類可讀的格式增強了協作並簡化了調試。 ``` // Inefficient { "customer_name_with_spaces": "John Doe" } // Efficient { "customerName": "John Doe" } ``` 2. **與語言無關**:JSON 不依賴任何特定的程式語言。它是一種通用資料格式,幾乎可以由所有現代程式語言解析和生成,因此具有高度通用性。 3. **資料結構一致性**:JSON 使用鍵值對、陣列和巢狀物件強制資料結構一致。這種一致性使其在各種程式設計場景中都可預測且易於使用。 ``` // Inefficient { "order": { "items": { "item1": "Product A", "item2": "Product B" } } } // Efficient { "orderItems": ["Product A", "Product B"] } ``` 4. **瀏覽器支援**:Web 瀏覽器原生支援 JSON,允許 Web 應用程式與伺服器無縫通訊。這種原生支援對其在 Web 開發中的採用做出了重大貢獻。 5. **JSON API**:許多Web服務和API預設提供JSON格式的資料。這進一步鞏固了 JSON 作為 Web 開發中資料交換首選的角色。 6. **JSON Schema**:開發人員可以使用 JSON Schema 來定義和驗證 JSON 資料的結構,為其應用程式添加額外的清晰度和可靠性。 有鑑於這些優勢,全球開發人員依賴 JSON 來滿足資料交換需求也就不足為奇了。然而,當我們更深入地探索部落格時,我們將發現與 JSON 相關的潛在性能挑戰以及如何有效解決這些挑戰。 ## 對速度的極品 在當今快節奏的數位環境中,應用程式速度和回應能力是不容談判的。用戶期望跨網路和行動應用程式即時存取資訊、快速互動以及無縫體驗。這種對速度的需求是由以下幾個因素所驅動的: ### 用戶期望 使用者已經習慣了數位互動中閃電般的快速回應。他們不想等待網頁加載或應用程式回應。即使是幾秒鐘的延遲也會導致沮喪和放棄。 ### 競爭優勢 速度可以成為顯著的競爭優勢。快速回應的應用程式往往比反應遲緩的應用程式更有效地吸引和留住用戶。 ### 搜尋引擎排名 像 Google 這樣的搜尋引擎將頁面速度視為排名因素。載入速度更快的網站往往在搜尋結果中排名更高,從而提高可見度和流量。 ### 轉換率 尤其是電子商務網站,他們敏銳地意識到速度對轉換率的影響。更快的網站可以帶來更高的轉換率,從而增加收入。 ### 移動效能 隨著行動裝置的普及,對速度的需求變得更加重要。行動用戶的頻寬和處理能力通常有限,因此需要快速的應用程式效能。 ### JSON 會減慢我們的應用程式速度嗎? 現在,讓我們解決核心問題:JSON 是否會減慢我們的應用程式速度? 如同前面提到的,JSON 是一種非常流行的資料交換格式。它靈活、易於使用且廣受支援。然而,這種廣泛的採用並不能使其免受性能挑戰。 在某些情況下,JSON 可能是降低應用程式速度的罪魁禍首。解析 JSON 資料的過程,尤其是在處理大型或複雜結構時,可能會消耗寶貴的毫秒時間。此外,低效率的序列化和反序列化可能會影響應用程式的整體效能。 ### 解析開銷 當 JSON 資料到達您的應用程式時,它必須經過解析過程才能將其轉換為可用的資料結構。解析可能相對較慢,尤其是在處理大量或深層巢狀的 JSON 資料時。 ``` // JavaScript example using JSON.parse for parsing const jsonData = '{"key": "value"}'; const parsedData = JSON.parse(jsonData); ``` ### 序列化與反序列化 JSON 要求資料從用戶端傳送到伺服器時進行序列化(將物件編碼為字串),並在接收時進行反序列化(將字串轉換回可用物件)。這些步驟可能會帶來開銷並影響應用程式的整體速度。 ``` // Node.js example using JSON.stringify for serialization const data = { key: 'value' }; const jsonString = JSON.stringify(data); ``` ### 字串操作 JSON 是基於文字的,嚴重依賴字串操作來進行連接和解析等操作。與處理二進位資料相比,字串處理可能會慢一些。 ### 缺乏資料類型 JSON 具有一組有限的資料類型(例如字串、數字、布林值)。複雜的資料結構可能需要效率較低的表示,導致記憶體使用量增加和處理速度變慢。 ``` { "quantity": 1.0 } ``` ### 冗長 JSON 的人類可讀設計可能會導致冗長。冗餘金鑰和重複結構會增加有效負載大小,導致資料傳輸時間更長。 ``` // Inefficient { "product1": { "name": "Product A", "price": 10 }, "product2": { "name": "Product A", "price": 10 } } ``` ### 沒有二進位支持 JSON 缺乏對二進位資料的本機支援。在處理二進位資料時,開發人員通常需要將其編碼和解碼為文本,這可能會降低效率。 ### 深度嵌套 在某些場景下,JSON資料可能會深度嵌套,需要遞歸解析和遍歷。這種計算複雜性可能會減慢您的應用程式的速度,尤其是在沒有最佳化的情況下。 --- > **與此類似,我與其他熱愛開源的開發人員一起在 Slack 上運行一個以開發人員為中心的社群。我們討論這些類型的主題、實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議、為開源做出貢獻以及一切有助於開發人員保持理智的事情;)畢竟,太多的知識也可能是危險的。* * > **我邀請您加入我們的免費社區(_沒有廣告,我保證,並且我打算保持這種方式_),參與討論,並分享您的經驗和專業知識。您可以填寫此表格,Slack 邀請將在幾天後收到您的電子郵件。我們有來自一些偉大公司(Atlassian、Gong、Scaler)的優秀人員,您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9)** 讓我們繼續... --- ## JSON 的替代方案 雖然 JSON 是一種通用的資料交換格式,但其在某些場景下的效能限制導致人們探索更快的替代方案。讓我們深入研究其中一些替代方案,並了解您何時以及為何選擇它們: ### 協定緩衝區 Protocol Buffers,也稱為 protobuf,是 Google 開發的二元序列化格式。它在速度和效率方面表現出色。這就是您可能考慮使用 Protocol Buffer 的原因: 1. **二進位編碼**:Protocol Buffers 使用二進位編碼,與 JSON 基於文字的編碼相比,它更緊湊,編碼和解碼速度更快。 2. **高效的資料結構**:Protocol Buffers 可讓您透過精確的類型定義高效的資料結構,從而實現更快的序列化和反序列化。 3. **架構演化**:Protocol Buffers 支援架構演化,這表示您可以在不破壞向後相容性的情況下更新資料結構。 ``` syntax = "proto3"; message Person { string name = 1; int32 age = 2; } ``` ### 訊息包 MessagePack 是另一種專為提高效率和速度而設計的二元序列化格式。以下是您可能考慮使用 MessagePack 的原因: 1. **緊湊性**:MessagePack 產生高度緊湊的資料表示形式,從而減少資料傳輸大小。 2. **二進位資料**:MessagePack 提供了對二進位資料的原生支持,非常適合涉及二進位資訊的場景。 3. **速度**:MessagePack 的二進位性質允許快速編碼和解碼。 ``` // JavaScript example using MessagePack for serialization const msgpack = require('msgpack-lite'); const data = { key: 'value' }; const packedData = msgpack.encode(data); ``` ### BSON(二進位 JSON) BSON,通常發音為“bee-son”或“bi-son”,是一種二進位序列化格式,主要用於 MongoDB 等資料庫。以下是您可能考慮使用 BSON 的原因: 1. **類似 JSON 的結構**:BSON 維護了類似 JSON 的結構,並添加了二進位資料類型,在效率和可讀性之間提供了平衡。 2. **二進位資料支援**:BSON 提供對二進位資料類型的原生支持,這有利於處理映像或多媒體等資料。 3. **資料庫集成**:BSON 與 MongoDB 等資料庫無縫集成,使其成為此類環境的自然選擇。 ``` { "_id": ObjectId("60c06fe9479e1a1280e6bfa7"), "name": "John Doe", "age": 30 } ``` ### 歐元 Avro 是在 Apache Hadoop 專案中開發的資料序列化框架。它強調模式相容性和效能。以下是您可能考慮使用 Avro 的原因: 1. **架構相容性**:Avro 優先考慮架構相容性,讓您在不破壞相容性的情況下發展資料結構。 2. **二進位資料**:Avro 使用緊湊的二進位編碼格式進行資料傳輸,從而產生更小的有效負載。 3. **語言中立**:Avro 支援多種程式語言,使其適合不同的應用程式生態系統。 ``` { "type": "record", "name": "Person", "fields": [ { "name": "name", "type": "string" }, { "name": "age", "type": "int" } ] } ``` JSON 及其替代方案之間的選擇取決於您的特定用例和要求。如果架構相容性至關重要,Avro 可能是最佳選擇。如果您需要緊湊性和效率,MessagePack 和 Protocol Buffers 是強有力的競爭者。在處理二進位資料時,MessagePack 和 BSON 可以滿足您的需求。每種格式都有其優點和缺點,因此請選擇適合您專案需求的格式。 ### 最佳化 JSON 效能 但是,如果您決心使用 JSON,儘管它有潛在的速度障礙,該怎麼辦?如何讓 JSON 運作得更快、更有效率?好消息是,有一些實用的策略和最佳化可以幫助您實現這一目標。讓我們透過程式碼範例和最佳實踐來探索這些策略。 **1.最小化資料大小** A。 **使用簡短的描述性鍵**:選擇簡潔但有意義的鍵名稱以減少 JSON 物件的大小。 ``` // Inefficient { "customer_name_with_spaces": "John Doe" } // Efficient { "customerName": "John Doe" } ``` b. **盡可能縮寫**:在不犧牲清晰度的情況下,考慮使用鍵或值的縮寫。 ``` // Inefficient { "transaction_type": "purchase" } // Efficient { "txnType": "purchase" } ``` **2.明智地使用數組** A。 **最小化巢狀**:避免深度巢狀數組,因為它們會增加解析和遍歷 JSON 的複雜度。 ``` // Inefficient { "order": { "items": { "item1": "Product A", "item2": "Product B" } } } // Efficient { "orderItems": ["Product A", "Product B"] } ``` **3.優化數位表示** A。 **盡可能使用整數**:如果一個值可以表示為整數,請使用它而不是浮點數。 ``` // Inefficient { "quantity": 1.0 } // Efficient { "quantity": 1 } ``` **4.刪除冗餘** A。 **避免重複資料**:透過引用共享值來消除冗餘資料。 ``` // Inefficient { "product1": { "name": "Product A", "price": 10 }, "product2": { "name": "Product A", "price": 10 } } // Efficient { "products": [ { "name": "Product A", "price": 10 }, { "name": "Product B", "price": 15 } ] } ``` **5.使用壓縮** A。 **套用壓縮演算法**:如果適用,請使用 Gzip 或 Brotli 等壓縮演算法來減少傳輸過程中 JSON 有效負載的大小。 ``` // Node.js example using zlib for Gzip compression const zlib = require('zlib'); const jsonData = { // Your JSON data here }; zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => { if (!err) { // Send compressedData over the network } }); ``` 根據塞繆爾的評論,我添加了一個編輯。 {% devcomment 2adn4 %} ``` As Samuel rightly observes, the adoption of HTTP/2 has brought significant advancements, particularly in optimizing data interchange formats like JSON. HTTP/2's multiplexing capabilities efficiently manage multiple requests over a single connection, enhancing responsiveness and reducing overhead. In practical terms, a comprehensive optimization strategy may involve both embracing HTTP/2 and utilizing compression techniques per your use-case, recognizing that each approach addresses specific aspects of network efficiency and performance. HTTP/2 excels in network-level optimization, while compression strategies enhance application-level efficiency, and the synergy between them can lead to substantial gains in data handling speed and resource utilization. ``` **6。使用伺服器端快取** A。 **快取 JSON 回應**:實作伺服器端快取以有效儲存和提供 JSON 回應,減少重複資料處理的需要。 **7.設定檔和優化** A。 **分析效能**:使用分析工具來識別 JSON 處理程式碼中的瓶頸,然後最佳化這些部分。 請記住,您實施的具體優化應符合應用程式的要求和約束。 ### 實際最佳化:在實作中加速 JSON 現在您已經探索了優化 JSON 的理論方面,現在是時候深入研究遇到 JSON 效能瓶頸並巧妙克服它們的實際應用程式和專案了。這些範例提供了有關用於提高速度和回應能力的策略的寶貴見解,同時仍利用 JSON 的多功能性。 **1. LinkedIn 的協定緩衝區整合** *挑戰:LinkedIn 與 JSON 冗長和網路頻寬使用的鬥爭* 全球最大的職業社交平台LinkedIn面臨嚴峻的挑戰。他們對 JSON 進行微服務通訊的依賴導致了冗長和網路頻寬使用量的增加,最終導致更高的延遲。在每一毫秒都至關重要的數位世界中,這是一個需要解決方案的挑戰。 **解決方案:協定緩衝區的力量** LinkedIn 轉向了 [Protocol Buffers](https://engineering.linkedin.com/blog/2023/linkedin-integrates-protocol-buffers-with-rest-li-for-improved-m),通常稱為 protobuf,由Google開發的二進位序列化格式。 Protocol Buffers 的主要優勢在於其效率、緊湊性和速度,使其在序列化和反序列化方面比 JSON 快得多。 **影響:延遲減少高達 60%** Protocol Buffers 的採用顯著降低了延遲,報告顯示延遲可提高高達 60%。此次優化顯著提高了 LinkedIn 服務的速度和回應能力,為全球數百萬用戶提供了更流暢的體驗。 **2. Uber 的 H3 地理索引** *挑戰:Uber 在地理空間資料方面的 JSON 困境* 叫車巨頭優步的營運嚴重依賴地理空間數據。 JSON 是表示地理空間資料的預設選擇,但解析大型資料集的 JSON 被證明是一個瓶頸,減慢了演算法的速度。 **解決方案:引入 H3 地理索引** Uber 推出了 [H3 Geo-Index](https://www.uber.com/en-IN/blog/h3/),這是一種用於地理空間資料的高效能六邊形網格系統。透過從 JSON 轉向這種創新解決方案,他們成功地大幅減少了 JSON 解析開銷。 **影響:加速地理空間操作** 這種優化大大加速了地理空間操作,提高了 Uber 乘車服務和地圖系統的效率。使用者體驗到更快的回應時間和更可靠的服務。 **3. Slack 的訊息格式最佳化** *挑戰:Slack 與即時訊息渲染的戰鬥* Slack 是團隊的訊息平台,需要在即時聊天中傳輸和呈現大量 JSON 格式的訊息。然而,這導致了效能瓶頸和訊息渲染緩慢。 **解決方案:簡化 JSON 結構** Slack 優化了 JSON 結構以減少不必要的資料。他們開始在每個訊息中只包含基本訊息,從而減少有效負載的大小。 **影響:更快的訊息渲染和增強的聊天效能** 此優化顯著提高了訊息渲染速度。 Slack 用戶享受到更靈敏、更有效率的聊天體驗,尤其是在繁忙的群組聊天中。 **4. Auth0 的協定緩衝區實作** *挑戰:Auth0的身份驗證和授權資料效能* Auth0 是一個著名的身份和存取管理平台,在處理身份驗證和授權資料時面臨 JSON 的效能挑戰。這些數據需要在不影響安全性的情況下有效處理。 **解決方案:採用協定緩衝區進行資料序列化** [Auth0 也轉向Protocol Buffers](https://auth0.com/blog/beating-json-performance-with-protobuf/#How-Do-We-Use-Protobuf),利用其高效的資料序列化和反序列化功能。此交換器顯著提高了資料處理速度,使身份驗證過程更快並增強了整體效能。 **影響:加速身份驗證和授權** Protocol Buffers 的採用增強了身分驗證和授權流程,確保 Auth0 的服務提供一流的效能,同時保持最高的安全標準。 這些現實世界的例子強調了優化在克服 JSON 相關的速度下降方面的力量。這些案例中採用的策略證明了 JSON 和替代格式在滿足現代數位環境的需求方面的適應性和多功能性。 請繼續關注結論部分,我們總結了關鍵要點,並為您提供了在您自己的專案中優化 JSON 效能的路線圖。 ## 結束語 在開發領域,JSON 是一種多功能且不可或缺的資料交換工具。其人類可讀的結構和跨語言適應性使其成為當代應用程式的基石。然而,正如我們在本指南中的探索所揭示的那樣,JSON 的普遍使用並不能使其免受性能挑戰。 我們在增強 JSON 效能的過程中獲得的重要收穫是顯而易見的: - 1. **效能至關重要:** 速度和反應能力在當今的數位環境中至關重要。用戶要求應用程式以閃電般的速度運行,即使是輕微的延遲也會導致不滿意並錯失機會。 - 2. **大小很重要:** 資料有效負載的大小直接影響網路頻寬使用和回應時間。減少資料大小通常是優化 JSON 效能的第一步。 - 3. **探索替代格式:** 當效率和速度至關重要時,探索替代資料序列化格式(如 Protocol Buffers、MessagePack、BSON 或 Avro)是有益的。 - 4. **真實世界範例:** 從組織有效解決 JSON 相關減速問題的真實實例中學習,表明最佳化工作可以顯著提高應用程式效能。 當您繼續開發和增強 Web 應用程式時,請務必牢記 JSON 對效能的影響。精心設計資料結構,選擇有意義的鍵名稱,並在情況需要時開放探索替代序列化格式。透過這樣做,您可以確保您的應用程式在速度和效率方面不僅滿足而且超越用戶的期望。 在不斷發展的 Web 開發環境中,優化 JSON 效能成為一項寶貴的資產,使您的專案與眾不同,並確保您的應用程式在即時數位體驗時代蓬勃發展。 --- > **與此類似,我與其他熱愛開源的開發人員一起在 Slack 上運行一個以開發人員為中心的社群。我們討論這些類型的主題、實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議、為開源做出貢獻以及一切有助於開發人員保持理智的事情;)畢竟,太多的知識也可能是危險的。* * > **我邀請您加入我們的免費社區(_沒有廣告,我保證,並且我打算保持這種方式_),參與討論,並分享您的經驗和專業知識。您可以填寫此表格,Slack 邀請將在幾天後收到您的電子郵件。我們有來自一些偉大公司(Atlassian、Gong、Scaler)的優秀人員,您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9)** > _如果您能與您的開發朋友(他們是奉獻者)分享該表格,我將不勝感激。_

Laravel 5.8 升級到 8.83 版本心得&筆記分享

手上有多個網站 都是 Laravel 5.8,放在一台 Ubuntu 18.04 的機器上(租用 Linode 機器) 四、五年了,一直沒去更新,最近終於下定決心來更新 首先把 Laravel 5 -> 6 -> 7 分多次升級,然後部署 都還算順利,官方的 upgrade guide 很清楚,簡單照做就完成 但是無法升到 laravel 8 因為需要 php 8 我那台 ubuntu 18.04 安裝 php 8 一直失敗 直接升級 OS 也失敗,一堆問題會出現 最後決定,在 Linode 租一台新的 Ubuntu 22.04 然後把專案通通搬過去 --- 因為專案中很多「用戶上傳的圖片」放在 local,所以都需要一起搬運 最後是用 scp 硬搬檔案 然後用 mysqldump 搬運資料 才終於順利升級到 laravel 8.83 了 詳細用到的指令大概像這樣 ``` scp -r [email protected]:/{PATH}/{FOLDER} /{PATH} scp -r [email protected]:/etc/apache2/sites-available/{CONF_FILE} /etc/apache2/sites-available/ a2ensite service apache2 reload create mysql user & database with phpmyadmin mysqldump --column-statistics=0 --default-character-set=utf8mb4 -h xxx.xxx.xxx.xxx -u {USER} --single-transaction -p{PASSWORD} {DATABASE} > /home/dump.sql; mysql -u root -p{PASSWORD} {DATABASE} < /home/dump.sql artisan down legacy site composer install -> new site is now online ``` --- 簡單筆記分享一下,希望能幫到一些人~ # Refs - https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-22-04#how-to-find-your-server-s-public-ip-address - https://itslinuxfoss.com/install-laravel-ubuntu-22-04-lts/ - https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04 - phpmyadmin password left blank, so it's random now - https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-phpmyadmin-on-ubuntu-22-04 - skip the whole Step 2 — Adjusting User Authentication and Privileges - `ssh-keygen` because I need a public key