2025年9月9日星期二

Vs code 編譯執行設定

步驟一:安裝 C/C++ 延伸模組與編譯器

安裝延伸模組:在 VS Code 中,開啟延伸模組市集(Ctrl+Shift+X),搜尋並安裝 C/C++ 延伸模組(由 Microsoft 提供)。
安裝編譯器:
如果使用的是 Windows,請安裝 MinGW-w64。
在安裝完成後,將編譯器路徑(通常是 C:\MinGW\bin 或 C:\mingw64\bin)加入到系統的 PATH 環境變數中。

步驟二:建立與設定 tasks.json

tasks.json 用於告訴 VS Code 如何編譯您的程式。它會被用來建置專案,也會在除錯前自動執行。
開啟專案資料夾後,按下 Ctrl+Shift+P,輸入 Tasks: Configure Task,然後選擇 Create tasks.json from template -> Others。
用以下內容覆蓋新生成的 tasks.json 檔案,這是一個專為您專案設計的多檔案編譯任務:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build my project",
            "type": "shell",
            "command": "gcc",
            "args": [
                "-g",
                "${workspaceFolder}/main.c",              // 加入編譯檔案
                "${workspaceFolder}/array_handler.c",// 加入編譯檔案
                "-o",
                "${workspaceFolder}/main.exe"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": false
            },
            "problemMatcher": ["$gcc"],
            "detail": "Builds the main.c and array_handler.c files."
        }
    ]
}

名稱功能說明

label: build my project 是您任務的名稱,這個名稱稍後會被 launch.json 引用。
args: 使用 ${workspaceFolder} 確保編譯器能從專案根目錄正確找到 main.c 和 array_handler.c。
group: 將此任務設為預設的建置(build)任務,這樣您可以直接使用 Ctrl+Shift+B 來執行。

步驟三:建立與設定 launch.json
launch.json 用於配置除錯器。它會指定如何啟動您的程式,並連結到 tasks.json 進行建置。
進入除錯視圖(Ctrl+Shift+D),點選左上角的「Run and Debug」按鈕,然後從下拉選單中選擇 C++ (GDB/LLDB)。
VS Code 會自動生成一個 launch.json 檔案。用以下內容覆蓋它:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug my project",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/main.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe", // 根據安裝路徑修改
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "build my project"
        }
    ]
}


步驟四:編譯與執行
完成以上設定後,依序點擊下圖。VS Code 會先自動執行編譯任務,然後啟動除錯器並執行程式。



2025年8月31日星期日

SHA3(Secure Hash Algorithm 3)

 最近在看 PQC (後量子密碼學) 的 ML SDA 當中有用到 SHA3 , 小有所感趁機紀錄以下的內容根據 FIPS 官方資料 (https://csrc.nist.gov/pubs/fips/202/final)進行閱讀後的整理

前言

在資訊安全領域裡,「雜湊函數(Hash Function)」是一個基礎但極其重要的工具。它能夠將任何長度的輸入訊息,轉換成固定長度的輸出(稱為訊息摘要)。這個摘要具有以下特性:

  • 不可逆:幾乎不可能從輸出反推出原始輸入。
  • 抗碰撞:不同的輸入幾乎不會產生相同的輸出。
  • 固定長度:無論輸入多大,輸出長度固定。

這些特性,讓 Hash 被廣泛應用於:

  • 驗證資料完整性(檔案驗證、下載檢查碼)。
  • 數位簽章與驗證。
  • 密碼學基礎建構(例如 HMAC、隨機數產生器)。

在過去幾十年,SHA(Secure Hash Algorithm, 安全雜湊演算法)系列成為最常用的雜湊家族。從 SHA-0、SHA-1 到 SHA-2,逐步守護著資訊安全。然而,隨著計算能力提升以及演算法分析技術進步,舊有的雜湊標準逐漸顯現弱點。這也引出了今天的主角:SHA-3。

SHA 的歷史

  • SHA-0(1993 年)
    • 第一版安全雜湊演算法,由美國國家安全局(NSA)設計並發表。
    • 由於存在安全弱點,很快就被棄用。
  • SHA-1(1995 年)
    • 改良後的版本,輸出長度為 160 位元。
    • 曾廣泛應用在 SSL、數位簽章、檔案驗證等場景。
    • 但隨著 2017 年 Google 公布實際碰撞攻擊實例,SHA-1 正式被視為不再安全。
  •     SHA-2(2001 年)
    • 包含多個版本:SHA-224、SHA-256、SHA-384、SHA-512。
    • 輸出長度更長,設計更安全,目前仍被廣泛使用。
    • 但其設計仍是基於 Merkle–Damgård 結構,若未來計算能力大幅提升,潛在風險依舊存在。

  •     SHA-3(2015 年,正式標準化)
    • 由 Keccak 演算法在 NIST(美國國家標準技術研究院)舉辦的雜湊演算法競賽中勝出。
    • 最大的不同是:架構完全不同。SHA-3 基於 Sponge 結構,而不是傳統的 Merkle–Damgård。
    • 這使得 SHA-3 在安全性與彈性上具備不同優勢,也能衍生出 SHAKE(可延伸輸出長度的雜湊函數)。

2025年7月12日星期六

職場對照觀察(一):產品開發與專案文化的不同樣貌

神戶港
來到新公司已經半年多了,經歷了一兩個完整專案,節奏逐漸穩定後,也讓我有機會重新回顧這幾年的職涯轉折。
特別是從前公司轉換到現在的環境後,我開始更清楚地意識到:一間公司的文化、制度、團隊氣氛,真的會深深影響一個人的工作方式、學習動力,甚至是對未來的想像。那些曾經以為「哪裡都差不多吧」的想法,其實在實際經歷後才發現——差異比我想像的更深、更遠。

這篇文章會先從【產品開發與專案文化】這個角度切入,分享我觀察到的差異、實際經驗中的轉變,以及這段過程中逐漸累積的反思與體會。後續我也會再整理【管理風格與人才培養】方面的內容,作為這段職涯觀察的下一篇,希望能成為職場上努力前行、或正面臨轉換的你,一點小小的參考與陪伴。

如果你還沒看過我之前的兩篇文章,也歡迎一起搭配閱讀,會更完整理解我這一路的思考與選擇:

《趁年輕離職,走向真正的理想人生》

《離職籌備計畫:從念頭到行動的過程》


產品開發與專案文化

1. 產品開發流程

舊公司:

為了搶市場時程,常犧牲系統架構與穩定性,專案開發過程中也常臨時變更方向,甚至整體架構說翻就翻。有時還會插入與原專案無關的任務,要你「一邊解決問題、一邊照常交付」,進度與品質雙雙承壓。

新公司:

專案啟動前會完整確認規格與需求,開發過程中不輕易變動方向,目標明確、按計畫執行,工程師能在相對穩定的節奏下推進工作。

小故事:

曾經在前公司主動建議使用新的平台架構,當時就已能預見現有系統無法支撐預期功能,建議如能一開始就重構,能有效解決核心問題。但因 PM 擔心時程無法交付,仍選擇沿用舊平台。
開發過程中,架構限制逐一浮現,最終導致專案反覆修補,設計翻新、流程重做,整體開發週期拉得更長、難以如期交付。儘管如此,我仍負責將專案完成到出國展示,直到任務告一段落才選擇離開——因為接下來,又要再一次改架構了。

2. 跨部門合作

舊公司:

合作有時會演變成爭執,會議中不是針對問題討論,而是誰吵贏就照誰的。即使最後決定了方向,氣氛也早已變質,主管之間的不合多少會影響到下屬,讓工程師之間的合作變得不那麼愉快。跨部門的問題,常常變成「互相推責」,而不是「一起解決」。

儘管如此,我還是盡量與合作工程師協調節奏,私下互相支援,心想:上面要吵就吵吧,只要不要干擾我們實際開發的進度就好。

新公司:

雖然也有磨合,但整體合作氛圍理性得多。會議中傾聽與討論是基本,不會動輒指責或推諉。即使有分歧,也能從問題本質出發,找出可以一起解決的方向,也不太會有情緒上的講話方式。

小故事:

曾經在一次跨部門會議中,某主管一邊滑手機、一邊參與討論,當請他協助確認時,他卻請專案主持人再重複一遍剛才講過的內容。某主管後來轉達公司宣導:「上班不要滑手機太誇張。」但由他宣達,說服力實在讓人存疑。
我觀察到的現實是,久而久之,員工也跟著鬆懈了,有人上班看球賽,甚至打起了遊戲。這種「上行下效」的現象,讓人感到無奈。
當然,我並不認為研發單位應完全禁止使用手機,偶爾放鬆、查資料、發想創意,甚至處理緊急事項,都是可以理解的。但若主管自己過度使用,卻反過來要求員工嚴格自律,那觀感真的會很差。

3. 工作與進修平衡

舊公司:

開發節奏常變,工程師白天被需求追著跑,下班還要處理突發狀況,加班成了常態,連假日也得進公司。
「進度沒達成就自己加班啊」——這句話從主管口中說出來特別刺耳。若需求合理、時程規劃得當,真的有必要加班嗎?開太短被質疑,開太長又說沒必要,最後往往是犧牲員工去滿足客戶。
看似很忙,實則只是用熟悉的方法硬撐,沒有時間學新技術,也無暇整理經驗。時間被切碎,精力被掏空,想成長卻沒有條件。
最令人無力的是,加班不是為了解決根本問題,而是補救架構老舊、規劃錯誤、人力錯配的結果。每天重複解類似的 bug、處理重複的 issue,工作在推進,成長卻停滯。
而最諷刺的是,公司雖然給加班費,卻又要求每月達到「超時時數」,準時下班還可能被嫌加得不夠。這樣的制度,讓人懷疑所謂「加班」是努力還是 KPI 考核的一環?
晚上九點,辦公室燈火通明,許多同事還在「努力」。但我逐漸明白,真正的努力,不該只是延長工時,而是要有推動自己前進的空間。在那樣的環境裡,連努力的方向都容易迷失。

新公司:

到了晚上七點,整層辦公室幾乎已經清空。這裡沒有人會以「加班」為榮,也沒有人期待靠延長工時來完成專案。
在專案初期,團隊會花時間進行討論,確認規格與技術方向,並與客戶端明確對齊,才正式展開開發。整體流程規劃合理,專案中途不會輕易變更方向。

資源配置清楚,讓新進同仁能快速上手、穩定推進專案。
公司也重視工作與成長的平衡。平常便安排內部技術分享與學習活動,而且是在上班時間進行,而非要求員工額外加班參與。新人也會輪流學習不同模組的功能與原理,提升全體技術水準,降低開發過程的依賴與斷點。
更讓人印象深刻的是,主管不只強調效率與成果,也會在專案提前完成時,主動安排聚餐、技術交流,甚至留白一兩天讓大家喘口氣、吸收新知。這樣的安排,讓人真切感受到:「進度壓力不必犧牲生活,完成工作不代表停止學習。」
主管們以身作則,強調合理工時與團隊合作。當上層不再用加班衡量責任,員工自然也不再用疲憊換取成就。這樣的文化,讓工作變得更可持續,學習與成長也得以同步推進。

小故事:

前公司有時會安排教育訓練在傍晚五點或六點進行。對一些早上八點甚至更早就進公司的員工來說,這樣的安排無形中拉長了一整天的工時,甚至有些部門是在下班開會。
雖然教育訓練的出發點可能是知識傳承或提升素養,但若內容只是為了應付 KPI 或形式上的時數,實際收穫有限,反而可能讓員工感到疲憊與無力。
這讓人思考一個問題:當員工的付出不被算作加班,卻仍需投入額外時間與精力時,這樣的制度是否真的達到了它原本的目的?還是只是在折損大家學習的意願?

4. 發生錯誤時的處理方式

舊公司:

錯誤發生時,公司會釐清成因,通常鎖定在功能開發端。但實務上,最終責任仍常落在「掛名工程師」身上,即使問題源頭在其他環節,也難以完全釐清。
新人訓練缺乏系統,很多時候也只能「自己摸索看看」,出錯卻又被責備「連這都不知道」,讓人無所適從。即使是超資深工程師,也常面臨苛責──即便已盡力處理,但因開發環境與架構老舊,難免仍有疏漏,卻被批評「你都資深了怎麼還會出這種錯?」忽略了這正是整體文化與制度問題所導致的結果。
最令人無奈的是:當錯誤發生在下屬身上,常被放大檢視;但若是主管自身的案子出問題,處理就顯得低調許多。雙重標準讓團隊信任感受損。即使主管事後願意下來協助,現場氣氛與信任關係也早已悄悄改變。

新公司:

錯誤被視為成長的一部分,而不是單方面的責備來源。即便犯錯,也能坦然面對,團隊會一同討論、修正,主管不會把問題推給個人,而是主動協助釐清原因,並將後續的改進點納入流程或文件中,讓整體制度更穩健。
這樣的文化不僅對新人適用,對資深工程師也一視同仁。當錯誤出現時,不會以「你都資深了還會這樣」作為指責,而是回到技術本質找解法。主管也能坦率面對自己的不足,並與大家一起調整方向,而不是試圖掩蓋或推責。

小故事:

在新公司有一位新人接手前人留下的功能模組,由於交接不夠完善,加上技術文件缺漏,導致在開發過程中遇到不少障礙。面對這樣的狀況,主管們並未將責任歸咎於新人,而是主動參與問題釐清,與新人一起討論模組邏輯與潛在風險。資深工程師也加入協助,從程式碼理解到測試驗證都逐步陪伴協助。


小結與想法

產品開發的流程是否穩定、跨部門是否理性合作、錯誤是否被建設性處理,這些看似日常的運作方式,其實正是影響職涯品質與成長幅度的核心因素。當制度明確、節奏合理,工程師能專注在實質的價值產出。
當錯誤被視為改進的機會而非責任歸屬的工具,技術團隊才有空間真正優化系統、累積經驗。
一間公司的文化,會逐漸內化為成員的工作習慣與思維模式,進而形塑出整體的專業風貌與學習氛圍。而這些因素,往往才是決定技術深度與職涯高度的關鍵。

後續將分享關於【管理風格與人才培養】的觀察,補足文化面向的另一側。


記得加入新公司不久,我去了一趟日本。沿路的風景、城市的節奏,讓我再次感受到:人生的寬度,不能只被工作綁住。
世界這麼大,值得走走看看。職涯只是人生的一部分,如果一份工作讓你交出了幾乎所有的時間與精神,那真的要停下來想一想,這是不是你想要的生活方式。
我們每個人都只有一段人生,不該為了公司體系而被困在原地,錯過那些本該屬於自己的風景。

神戶港(Kobe Port)

打賞按讚