Home

網際網路邊界閘道協定（BGP）

本文章探討網際網路邊界閘道協定（BGP），這是一種標準化的外部閘道協定，設計用於在互聯網上的不同自治系統（ASes）或網際網路服務提供商（ISP）之間交換路由和可達性資訊。以下，我們詳細介紹了與此協定相關的重要性、能力、挑戰和解決方案。

1. 邊界閘道協定及其功能

1989年1月，在第12次網際網路工程任務組（IETF）會議上，Len Bosack、Kirk Lougheed和Yakov Rekhter創造了BGP，其設計目標是開發一種能夠提供政策控制、迴路檢測以及通過地址聚合技術支持數十萬個網路的協定。

BGP作為一種自治系統間的路由協定，便利了ISPs之間的連接。例如，和記黃埔和中國移動交換網路層可達性資訊（NLRI）。在互聯網缺乏集中控制的環境中，這些實體必須交換NLRI以整合他們的自治網路。每一個都控制自己的設備並使用不同的自治系統內部路由協定；他們需要合作來交換與他們的客戶相關的IP地址資訊。

一個使用 BGP 的系統的主要功能已演變為解決這個工程和研究問題：使自治網路之間能交換資訊，而無需集中式控制。發送到服務提供商的數據包需要進行查找才能決定下一個目的地，可能是中國另一邊的完全不同的網絡。BGP是全球 TCP/IP 網路的基本架構。

BGP的另一個重要角色是管理商業問題。例如，中國移動可能不希望和記黃埔發送過量的流量，因為這將增加額外的成本。這些自治網絡內部運行著不同的協定，「最佳路徑」可能會根據合同和政策而有所不同。BGP提供了靈活性，可以定義對不同方來說什麼是最佳路徑。

2. BGP的運作

BGP的當前版本是版本4，於2006年以RFC 4271的形式出版。BGP使用一種路徑向量算法，而不是純粹的距向量或連接狀態算法。它使用存儲在AS_PATH屬性中的路徑資訊來避免傳統路由問題。路由表被遍歷以到達目標網絡，從而提供迴路避免。BGP還支持地址聚合，從而大大減少了核心互聯網路由表的大小。

當一條互聯網路徑失效時，BGP提供了網路穩定性，使路由器能夠快速適應和重新路由數據包。每個BGP路由器都維護一個標準路由表，該表與路由資訊庫（RIB）一起使用，並在變化發生時不斷更新。

BGP只在變化發生時更新路由表資訊。它缺少自動發現機制，這意味著必須手動建立對等連接。該協定使用一種增量更新策略，以節省帶寬和處理能力，依賴TCP來提供可靠的傳輸。

3. 舉例說明ASes如何了解網際網路的可達性

可以假設我們有五個由唯一的32位自治系統號（ASN）標識的ASes，如下所示：

BGP允許這些ASes內的路由器通過內部和外部的BGP說明者來學習多條路徑。它選擇最佳路徑並將其安裝在RIB中。當AS104網絡中的一個客戶希望將數據發送到AS100網絡時，BGP幫助AS104內的路由器決定哪條路徑走，並相應地更新可達性資訊。

BGP還提供了對不同服務提供商之間的信任和不信任的管理，並且在RFC 4271中進行了描述。它允許具有共同路由政策的網絡能夠被唯一的標識，並且被廣泛地用在互聯網的骨幹網絡上。

BGP確定最佳路徑的決策依賴於當前的可達性、跳數和其他路徑屬性。它可以被配置為告知一個組織的路由偏好，並且有一個定義任意標簽（即社區）的機制，以控制經過對等體之間的共同協議的路由廣告行為。

4. BGP包格式和欄位函數

BGP消息通過TCP連接進行傳輸。只有在消息完全接收後才進行處理。消息的最大尺寸為4096字節，而最小允許的消息由一個19字節的頭部組成，而沒有任何數據。以下我們突出了一些欄位的功能：

4.1 消息頭部格式

標記：這是一個16字節的欄位，用於相容性，必須設置為全1。

長度：這是一個2字節的無符號整數，表示消息中包括頭部在內的總長度，以字節為單位。它有助於在TCP流中找到下一條消息的標記欄位。欄位值必須始終大於19並小於4096。消息後面不能填充額外的數據，因此該欄位必須包含最小的必需值。

類型：這是一個1字節的無符號整數，指定消息的類型代碼。類型代碼有：1-Open、2-Update、3-Notification、4-Keepalive。

4.2 Open消息格式

建立TCP連接後，雙方首先發送的消息是Open消息。如果Open消息是可以接受的，則回發送一個確認Open的Keepalive消息。

版本：這是一個1字節的無符號整數，表示消息的協定版本號。

我的自治系統：這是一個2字節的無符號整數，指定發件者的AS號碼。

保持時間：這是一個2字節的無符號整數，表明在秒中的保持計時器的值。在收到一條Open消息後，BGP講話者透過取其配置的保持時間和收到的保持時間中的較小者來計算保持計時器。此時間必須為0 或 至少為3秒。可能會根據此時間值拒絕連接。

BGP標識符：這是一個4字節的無符號整數，標識發件人的BGP標識符。該值在啟動時確定，並在所有本地接口與BGP對等方保持一致。

Opt Param Len：這是一個1字節的無符號整數，顯示可選引數欄位的總長度，以字節為單位。零值表示沒有提供可選引數。

可選參數（變量）：此欄位包含一個參數列表，每個參數分別編碼如下：

• 參數類型：1字節欄位用於識別個別參數。
• 參數長度：1字節欄位指定參數值欄位的長度，以字節為單位。
• 參數值（變量）：根據參數類型欄位的值來詮釋。

Open消息的最小長度（包括頭部）為29個字節。

4.3 Update消息格式

此格式用於在BGP對等體之間交換路由資訊，有助於構建表示各種自治系統（AS）之間關係的圖。它通過識別並消除路由迴路和其他的自治系統間路由異常。

Update消息可以用來廣告具有共同路徑屬性的可行路徑，或撤銷多條不可行的路徑。它可以在同時廣告一條可行路徑和撤銷多條不可行路徑。

撤銷的路徑長度（2個字節）：指示撤銷路徑欄位的總長度；值為0表示沒有路徑被撤銷。

撤銷的路徑（變量）：包含被撤銷路徑的IP地址前綴的列表。

長度（1個字節）：以位為單位指定IP地址前綴的長度；值為0與所有IP地址的匹配。

前綴（變量）：包含一個IP地址前綴，以及為在字節邊界上對齊欄位結尾需要的最少尾隨位數。

總路徑屬性長度（2個字節）：指示以字節為單位的路徑屬性欄位的總長度。值為0表示沒有 NLRI 或 path 屬性欄位存在。

路經屬性（可變）：由<屬性類型，屬性長度，屬性值>組成的 3 元組。 屬性類型是一個 2 字節的欄位，其中包括：

• 屬性標誌：各種位用於不同的目的，如選擇位、轉移位、部分位和擴展長度位。
• 屬性類型代碼：如原始碼、AS_PATH、NEXT_HOP、MULTI_EXIT_DISC、LOCAL_PREF、原子聚合和聚合器指定了不同類型的路徑屬性。

網路層可達性資訊（變量）：包含一個 IP 地址前綴的列表。其長度並不直接編碼，但可以使用以下式子計算：

( \text{更新消息長度} - 23 - \text{路徑屬性長度總計} - \text{撤銷路徑長度} )

• 「更新消息長度」是固定大小的BGP首部中編碼的值。
• 「路徑屬性長度總計」和「撤銷路徑長度」是更新消息的變動部分。
• 23是固定大小的BGP頭部、路徑屬性長度和撤銷路徑長度的總和。

達性資訊是以一個或多個2元組編碼，每個都有：

長度（1個字節）：以位為單位指出 IP 地址前綴的長度。值為0與所有 IP 地址的匹配，自身前綴包含零個字節。

4. 在BGP中的包格式及突出一些欄位的功能

BGP消息通過TCP連線發送。僅在接收到整個消息後才進行處理。消息的最大尺寸為4096個八位組，而最小合理的消息由19個八位組的標頭組成，不含任何數據。以下，我們突出了某些欄位的功能：

4.1 消息標頭格式

• 標記：這是一個16個八位組的欄位，為了與過去的協議版本相容，必須設定為全為一。

• 長度：這是一個2個八位組的無號整數，表示包含標頭在內的消息的總長度，單位為八位組。須以此欄位的值間接找出TCP資料流中下一個消息的標記欄位。欄位值必須永遠大於19且小於4096。禁止在消息後面填充額外的數據，因此這個欄位的值必須只含最小所需的值。

• 類型：這是一個單個八位組無號整數，指定了消息的類型碼。類型碼為：1-Open、2-Update、3-Notification、4-Keepalive。

4.2 Open消息格式

在建立TCP連線後，每一方首先發送的消息是一條open消息。如果收到的open消息可以被接受，就會回應一條確認接收open消息的keepalive消息。

• 版本：這是一個單個八位組無號整數，顯示了消息的協議版本號。

• 我的自治系統：這是一個2個八位組無號整數，表明了發送者的AS編號。

• 保持時間：這是一個2個八位組無號整數，表示了保持計時器的值建議，單位為秒。在收到open消息時，一個BGP有聲人應當通過取配置的保持時間和已接收到的保持時間中的最小值來計算保持計時器。此時間必

Pseudo-Scrum - A Hybrid of Waterfall and Agile

I have something to tell you: you're not truly agile. You may have gone through the motions, performing all the scrum rituals like stand-ups, demos, and retrospectives. You may even have all the requisite tools like JIRA, user stories, and a scrum board. However, if the mindset isn't right, something fundamental is still missing. Here's why:

You Have a Detailed Plan

You're adhering to a strict year-long deadline. Scrum teams calculate velocity based on estimates made during sprint planning. So, how can you expect the scrum team to align with top management's best guesses? When the roadmap is fixed, the scope is unchanging, and the release plan is impractical, you're actually following a waterfall model.

Absence of a True Scrum Master

You may have a Scrum Master on your org chart, but what's their actual role? Often, the person isn't a full-time Scrum Master but a project manager, product owner, or senior developer who isn't wholly committed to the role. When the Scrum Master is juggling multiple responsibilities, things start to derail. Even if you do have a dedicated Scrum Master, they may not be able to address real impediments due to technical complexities or constraints beyond their job description.

No Designated Product Owner

Someone needs to be in charge of the product, but often that person is preoccupied with other priorities. Without a clear vision and product ownership, feature development may go awry. This is particularly true when requirements are dictated by external senior directors, leading to wasted development efforts. While the product owner should make these decisions, few are willing to take the risks and many are unsure of what they actually want.

Lack of a Budgeting Strategy

Story points are not a substitute for budgeting. When you manipulate estimates to secure more funds and time, or negotiate downward to meet budget constraints, you lose sight of the team's true velocity. Traditional accounting methods are also not compatible with agile development. Skimping on budget often leads to team burnout without achieving the intended outcomes.

My Take on the Agile Manifesto

Here's how I interpret the Agile Manifesto in my own words: Prioritize responsiveness to change over adhering to a strict roadmap set by senior management. Value individuals and interactions over office politics. Emphasize working software over endless, pointless meetings. Favor customer collaboration over budget negotiations. Achieving this is no simple task, but it's the only way for bureaucratic organizations to adapt and thrive in the digital age.

Pseudo-Scrum - A Hybrid of Waterfall and Agile

Welcome to Continuous Improvement, the podcast where we explore the challenges of achieving true agility in today's organizations. I'm your host, Victor, and in today's episode, we're going to dive into why you might not be as agile as you think you are.

Picture this scenario: you've implemented all the scrum rituals, you have the tools and processes in place, but if the mindset isn't right, something fundamental is still missing. So, let's break it down, starting with the first reason why you might not be truly agile.

Reason number one: you have a detailed plan. Now, don't get me wrong, planning plays an essential role, but when the roadmap is fixed, the scope is unchanging, and the release plan is impractical, you're actually following a waterfall model. Scrum teams need the flexibility to adapt to change and align with top management's evolving priorities.

Moving on to reason number two: the absence of a true Scrum Master. Sure, you may have someone with the title on your org chart, but what's their actual role? Often, the Scrum Master is juggling multiple responsibilities, which leads to a lack of focus and derails the agile process. Even if you do have a dedicated Scrum Master, they may not have the authority or ability to address real impediments, hindering the team's progress.

Reason number three: no designated Product Owner. Someone needs to be in charge of the product, providing a clear vision and taking ownership. However, many times, the person in this role is preoccupied with other priorities, causing feature development to go off track. It's essential to have a Product Owner who can make informed decisions and guide the team effectively.

Now let's talk about reason number four: the lack of a budgeting strategy. Story points are not a substitute for proper budgeting. Manipulating estimates to secure more funds or negotiating downward to meet budget constraints only distorts the team's true velocity. Traditional accounting methods often clash with agile development, leading to burnout and compromised outcomes.

Finally, let me share my take on the Agile Manifesto. Prioritize responsiveness to change over adhering to a strict roadmap set by senior management. Value individuals and interactions over office politics. Emphasize working software over endless, pointless meetings. And most importantly, favor customer collaboration over budget negotiations. It's not an easy task, but it's the only way for bureaucratic organizations to adapt and thrive in the digital age.

And that's a wrap for today's episode of Continuous Improvement. I hope you've gained valuable insights into the key factors that may be hindering your organization's agility. Remember, it's not just about going through the motions, but embracing the mindset of continuous improvement.

Join me next time as we explore strategies to overcome these challenges and truly unlock the power of agility within your organization. Until then, keep striving for progress and continuous improvement.

偽Scrum - 瀑布式和敏捷的混合體

我有些事情要告訴你：你並非真正的敏捷。你可能已經完成了所有的 Scrum 儀式，如站立會議、示範和檢討。你甚至可能有所有必要的工具，如JIRA、使用者故事和Scrum看板。然而，如果心態不正確，那麼某些基本的東西仍然缺失。以下是原因：

你有一個詳細的計劃

你正在堅持嚴格的一年期限。Scrum團隊根據在衝刺計劃期間做出的估算來計算速度。那麼，你怎麼能期待Scrum團隊與高層管理的最佳猜測相符呢？當路線圖是固定的，範圍不變，並且發布計劃不切實際時，你實際上正在遵循瀑布模型。

真正的Scrum Master缺席

你的組織圖上可能有一個Scrum Master，但他們的實際角色是什麼？通常，這個人不是全職的Scrum Master，而是一個項目經理、產品擁有者或者資深開發者，他們並未全心投入這個角色。當Scrum Master兼顧多項責任時，事情就開始出軌。即使你有一個專門的Scrum Master，他們可能也無法解決由於技術複雜性或超出他們工作職責的限制所帶來的實際障礙。

沒有指定的產品擁有者

需要有人負責產品，但通常這個人會被其他優先事項所佔據。如果沒有明確的視野和產品所有權，特性開發可能會出錯。當要求由外部高級主管指導時，這一點尤其正確，導致開發努力被浪費。雖然產品擁有者應該做出這些決定，但很少有人願意冒這些風險，許多人對他們實際想要什麼並不確定。

缺乏預算策略

故事點並不能替代預算。當你操縱估算來獲得更多的資金和時間，或者為了符合預算限制而向下談判，你就會對團隊的真實速度失去了視覺。傳統的會計方法也與敏捷開發不兼容。在預算上吝嗇往往會導致團隊燒休息，而不達到預期的結果。

我對敏捷宣言的看法

以下是我用自己的話來解釋敏捷宣言：把對變化的反應性放在遵循高級管理層設定的嚴格路線圖之上。尊重個人和互動超過辦公室政治。強調工作軟體超過無休止，毫無意義的會議。偏愛客戶合作超過預算談判。實現這一點並非易事，但對於官僚機構來說，這是在數位時代適應和繁榮的唯一途徑。

Deploying a Koa.js Application to an AWS EC2 Ubuntu Instance

I am developing an application using Koa.js, a new web framework created by the team behind Express. In this step-by-step tutorial, I'll guide you through deploying a Koa.js application on an Amazon Web Services (AWS) Ubuntu server.

Launching the Ubuntu Instance on AWS

First, launch an Ubuntu instance on AWS. You'll need to modify the security group settings.

If you don't make these changes, attempting to access the public domain in a browser will result in a "Connecting" state until it times out, rendering the site unreachable.

By default, the launch wizard only enables SSH.

Click the "Edit" button to add inbound rules for HTTP port 80 and HTTPS port 443.

Installing Node.js

SSH into your instance and install Node.js according to the official documentation:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

Setting Up Nginx as a Reverse Proxy Server

Next, install Nginx:

sudo apt-get update
sudo apt-get install nginx

Open the configuration file and make the following edits. Don't forget the semicolons:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/yourApp;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Save the file and restart the Nginx service:

sudo systemctl restart nginx

Deploying Your Application

Clone your Git repository into the /var/www/yourApp directory. You'll likely encounter a "Permission Denied" error, so change the ownership of the folder:

sudo chown -R ubuntu /var/www

Create a simple app.js to run your server:

var koa = require("koa")
var app = koa()

// logger
app.use(function* (next) {
  var start = new Date()
  yield next
  var ms = new Date() - start
  console.log("%s %s - %s", this.method, this.url, ms)
})

// response
app.use(function* () {
  this.body = "Hello World"
})

app.listen(3000)

Start the server:

node app.js

Open your browser and navigate to your public domain. You should see your Koa.js application running.

Done! Feel free to leave a comment below if you have any questions. :)

Deploying a Koa.js Application to an AWS EC2 Ubuntu Instance

Hello everyone, and welcome to "Continuous Improvement," the podcast where we explore different strategies and techniques for improving our skills and knowledge in the technology world. I'm your host, Victor, and in today's episode, we're going to dive into deploying a Koa.js application on an Amazon Web Services (AWS) Ubuntu server.

But before we begin, a quick reminder to subscribe to our podcast on your favorite platform and follow us on social media to stay updated on all our latest episodes. Alright, let's get started!

The first step in deploying our Koa.js application is to launch an Ubuntu instance on AWS. Now, it's important to modify the security group settings to ensure our application is accessible.

As you can see in the images provided in the blog post, it is necessary to add inbound rules for HTTP port 80 and HTTPS port 443. Without these changes, accessing the public domain in a browser would result in a "Connecting" state, eventually timing out and rendering the site unreachable.

Now that we have our Ubuntu instance set up, the next step is to install Node.js, the runtime environment for our Koa.js application. SSH into your instance and follow the official documentation instructions to install Node.js.

With Node.js successfully installed, we now move on to setting up Nginx as a reverse proxy server. Nginx will help us route traffic to our Koa.js application.

First, we need to install Nginx by running the appropriate commands. Once that's done, we'll open the Nginx configuration file and make the necessary edits, including adding the server block with the reverse proxy settings. Don't forget those semicolons!

After saving the configuration file, we need to restart the Nginx service to apply the changes.

Now that our server and reverse proxy are set up, it's time to deploy our Koa.js application. Clone your Git repository into the /var/www/yourApp directory on the Ubuntu instance. Keep in mind that you may encounter a "Permission Denied" error, but it can be easily fixed by changing the ownership of the folder.

Great! With the application files in place, it's time to create a simple app.js file to run our Koa.js server. The code in this file sets up a basic Koa.js server with a logger and a response that says "Hello World".

We're almost there! Just a few more steps. Start the server by running the node app.js command in the terminal.

And finally, open your browser and navigate to your public domain. If everything was done correctly, you should now see your Koa.js application running.

Congratulations! You've successfully deployed your Koa.js application on an AWS Ubuntu server. I hope this step-by-step guide has been helpful to you. If you have any questions or need further assistance, please feel free to leave a comment on the blog post.

That wraps up this episode of "Continuous Improvement." I hope you found the information valuable and that it inspires you to continue expanding your skills and knowledge. Don't forget to subscribe to our podcast and follow us on social media for more episodes like this one. Thanks for tuning in, and until next time, keep improving!

heroImage: '/2017-01-07.png'---

將 Koa.js 應用程式部署至 AWS EC2 Ubuntu 實例

我正在使用 Koa.js 開發一個應用程式，這是一個由 Express 團隊創建的新網頁框架。在這個逐步教學中，我將指導您如何在 Amazon Web Services (AWS) Ubuntu 伺服器上部署 Koa.js 應用程式。

在 AWS 上啟動 Ubuntu 實例

首先，在 AWS 上啟動一個 Ubuntu 實例。您需要修改安全組設定。

如果您沒有進行這些更改，試圖在瀏覽器中訪問公共域將導致“連接”狀態，直到超時，導致無法訪問網站。

默認情況下，啟動嚮導僅啟用 SSH。

點擊“編輯”按鈕以添加適用於 HTTP 端口 80 和 HTTPS 端口 443 的入站規則。

安裝 Node.js

通過 SSH 登入您的實例並根據官方文檔安裝 Node.js：

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

設置 Nginx 作為反向代理伺服器

接下來，安裝 Nginx：

sudo apt-get update
sudo apt-get install nginx

打開配置文件並進行以下編輯。別忘了分號：

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/yourApp;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

保存文件並重新啟動 Nginx 服務：

sudo systemctl restart nginx

部署您的應用程式

將您的 Git 存儲庫克隆到 /var/www/yourApp 目錄。您可能會遇到“Permission Denied”錯誤，所以更改文件夾的所有權：

sudo chown -R ubuntu /var/www

創建一個簡單的 app.js 來運行您的伺服器：

var koa = require("koa")
var app = koa()

// logger
app.use(function* (next) {
  var start = new Date()
  yield next
  var ms = new Date() - start
  console.log("%s %s - %s", this.method, this.url, ms)
})

// response
app.use(function* () {
  this.body = "Hello World"
})

app.listen(3000)

啟動伺服器：

node app.js

打開您的瀏覽器並導航到您的公共域。您應該看到您的 Koa.js 應用程式正在運行。

完成！如果您有任何問題，請隨時在下面留言。:)

Lessons Learned from an IoT Project

Last year, I worked on an Internet of Things (IoT) project focused on a Bluetooth smart gadget. The experience differed significantly from pure software development in several ways:

Firstly, integration posed a challenge because the project's mechanical, firmware, mobile app, and design components were outsourced to multiple vendors. These vendors had geographically dispersed teams and varying work cultures. When developers are so specialized in their fields that they work in silos, the Scrum model is unlikely to function effectively.

Secondly, the duration of hardware iterations far exceeded that of software iterations, making it difficult to adapt to changes. Unlike software, which can be easily modularized, many hardware components like chips and motherboards are interconnected. This situation pushes the development process toward a more waterfall-like approach. You either receive the entire prototype or nothing at all; there's no middle ground for delivering a Minimum Viable Product (MVP) for consumer testing. The absence of early user feedback further hampers the feature prioritization process.

Thirdly, diagnosing issues becomes particularly challenging when things go wrong. It's difficult to determine whether the problem lies in the mechanical design, firmware, or mobile app development. Additionally, end-to-end testing becomes more complex as interfaces evolve. Conducting tests without comprehensive hardware automation was also time-consuming. To alleviate this, it's essential to have clearly defined and testable acceptance criteria, ensuring a strict definition of "done."

Effective communication is crucial for the success of any IT project, especially when various aspects aren't progressing as planned. Finger-pointing and defensiveness can severely damage interdepartmental relationships. Effective communication requires empathy; try to understand issues from the other person's perspective instead of reacting emotionally or judgmentally.

Customers assess performance based on the value they derive from a product. Adopting an empathetic and problem-solving mindset can reduce wasted time and effort, thereby improving overall performance. I look forward to the product's release and the positive reactions from its end-users.

Lessons Learned from an IoT Project

Hello, and welcome to Continuous Improvement, the podcast where we explore the challenges and triumphs of project development in the ever-evolving landscape of technology. I'm your host, Victor, and today we're discussing a topic close to my heart: the experience of working on an Internet of Things project.

Last year, I had the opportunity to work on a fascinating project focused on a Bluetooth smart gadget. But let me tell you, it was quite a departure from pure software development. Today, I want to share with you some of the unique challenges I faced and the lessons I learned along the way.

One of the major challenges I encountered was the integration of various components. You see, different aspects of the project, such as mechanical, firmware, mobile app, and design components, were outsourced to multiple vendors. And to make things even more complex, these vendors had geographically dispersed teams and different work cultures. It was like putting together a puzzle with pieces from different boxes.

When developers are so specialized that they work in silos, the standard Scrum model doesn't function as effectively. Collaboration becomes essential, and that's when effective communication truly shines.

Another hurdle I faced was the difference in duration between hardware and software iterations. Unlike software, which can be easily modularized, hardware iterations take a much longer time. This made adapting to changes and delivering a Minimum Viable Product (MVP) for consumer testing quite challenging. And without early user feedback, prioritizing features became a tough task. It almost felt like a waterfall-like approach in a fast-paced technology world.

Additionally, diagnosing issues became a puzzle of its own. With multiple components from different vendors, it was difficult to determine whether problems stemmed from mechanical design, firmware, or mobile app development. End-to-end testing also grew more complex as interfaces evolved. And without comprehensive hardware automation, testing became a time-consuming process.

So, what did I learn from these unique challenges? Well, it all comes down to effective communication and problem-solving mindset. Empathy is crucial. Instead of pointing fingers or becoming defensive, it's vital to understand issues from the other person's perspective. Building strong interdepartmental relationships is essential for the success of any IT project.

Customers judge the performance of a product based on the value they derive from it. By adopting an empathetic and problem-solving mindset, we can reduce wasted time and effort, ultimately improving overall performance.

And with that, we've reached the end of today's episode. I hope you found my insights into IoT project development valuable. Remember, embracing continuous improvement is key to succeeding in this ever-changing landscape.

Join me on the next episode of Continuous Improvement, where we'll dive into another fascinating topic. Until then, happy developing!

從物聯網項目中吸取的教訓

去年，我參與了一個專注於藍牙智能裝置的物聯網（IoT）項目。這個經驗與純軟體開發在幾個方面有顯著的不同：

首先，集成帶來了挑戰，因為項目的機械設計、固件、手機應用程式和設計組件被分包給多個供應商。這些供應商有地理上分散的團隊和不同的工作文化。當開發人員在他們的領域專門化到組織成獨立的群體時，Scrum模型不太可能有效運行。

其次，硬體迭代的時長遠超過軟體迭代，使其難以適應變化。與軟體不同，軟體可以輕易被模塊化，許多硬體組件如晶片和主機板卻是相互關聯。這種情況推動了開發過程向著更像瀑布模型的方向。你只能收到整個原型或者一無所有；沒有傳遞一個用於消費者測試的最小可行產品（MVP）的中間地帶。早期用戶反饋的缺乏進一步阻礙了特性優先級的確定過程。

第三，當事情出錯時，診斷問題尤其具有挑戰性。很難確定問題是出在機械設計、固件還是手機應用程式的開發。此外，隨著介面的演變，端到端的測試變得更加複雜。在沒有全面的硬體自動化的情況下進行測試也很耗時。為了緩解這一點，有必要明確並可驗證的接受準則，確保“完成”的嚴格定義。

對任何IT項目的成功而言，有效的溝通至關重要，特別是當各個方面沒有按計劃進展時。指責和防衛可以嚴重損害部門之間的關係。有效的溝通需要同理心；嘗試從他人的角度理解問題，而不是情緒化或判斷式地反應。

客戶根據他們從產品中獲得的價值來評估性能。採取同理心和解決問題的思維方式可以減少浪費的時間和精力，從而提高整體性能。我期待著產品的發佈和最終用戶的積極反饋。