補作業之AI微調LLM - Gemma3:270m + 繁體中文支援

前言:

要學習微調LLM，那就跟隨前輩作業，試著將Gemma3:270m加上繁體中文支援。
https://www.facebook.com/groups/gaitech/posts/1461027975081413/

成果:

整份專案在
https://gitlab.com/ycfunet/mi50_training_test

實做過程:

我用MI50微調訓練，讓Claude Code實做微調程式，一開始直接用Transforms訓練，結果一直出現Grad norm = NaN，Grad norm = NaN並不是一開始出現，也不是固定位置出現，是隨機位置出現，可能80%出現，可能95%出現，都會讓訓練失敗，微調出的模型，回答要嘛沒內容，要嘛出現padding，或者常見的出現各國語言混雜一段一段的回答錯亂。

後來用unsloth之後，發現unsloth微調都能正常訓練完，微調出的模型，中文問答都能中文回答。

雖然還有些問題，但原則上都能正確回答。

另外，完整微調真的很花時間，MI50一張，500k的繁體中文資料集，需要連續60幾小時訓練。

unsloth的記憶體使用量比想像少很多，用unsloth訓練時，GPU VRAM是浮動的，但最多也就12%，用量還不到4GB顯卡記憶體。

花費2週，算是有點成果，細節熟悉度還不夠，但入門算有點點進展吧。

補充:

對了，先前用colab T4微調馬達狀態機，這次也移到MI50上，發現MI50訓練的時間，跟colab T4差不多，估計MI50和colab T4同等級。

AI協作MongoDB設計工具 - Mongo Modeler(Modified)

 前言:

在實做了dbdiagram-oss之後，如果是NoSQL像是MongoDB，有沒有類似的方式或工具呢？
我找到了Mongo Modeler(github)，這個有團隊在開發和維護，而且一樣是純前端的工具，所以，應該應該可以無痛移植dbdiagram-oss後端吧。😁

以Mongo Modeler(github)為基礎用claude-code透過Vibe-Coding修改和實做，實做完成。

成果:

整份專案在
https://gitlab.com/ycfunet/mongo_modeler

實做過程:

它的後端幾乎不用改就能用，所以大部分都是前端修改工作。
考慮到Mongo Modeler還在持續維護和更新，我希望盡可能少的改動，Claude Code給了我實做建議 - JavaScript注入，非常聰明而有效。

因此，這個專案的前端改動，都是用外掛，以注入方式完成的，效果相當好。

但在Release前的測試時發現，MCP工具有點問題。😅

果然，問題總在意料外的地方出現。

MongoDB有定義Document的json結構，但這結構並沒有描述Collection之間的「關聯線(Relationships)」，但是Mongo Modeler是可以設定Collection間的關聯線(Relationships)，並且能夠顯示，那它如何儲存的？

原理很簡單，Mongo Modeler有自己的json資料格式， Mongo Modeler資料格式中包括了Collection的座標以及關聯線(Relationships)描述。

但因為Mongo Modeler的json格式並不是標準，因此LLM不會有格式的資訊，LLM只認識MongoDB的Document json結構，這怎麼辦呢？

為此，我請Claude Code修改了MCP Server程式，先實做一個轉換程式碼，用來雙向轉換MongoDB ⮂ Mongo Modeler的json格式。接著想了想，讓它在get function同時回傳2種格式的內容，LLM就能透過回傳的內容知道2種格式的對應關係和Mongo Modeler格式樣式。接著修改create和modify，分別實做create和create_mongo以及modify和modify_mongo，這樣能夠讓LLM用這兩種格式建立和修改schema json，讓Ai能夠與Mongo Modeler協作。

Claue Code改的程式碼很厲害，它實做時強調，如果建立時是Mongo Modeler格式，修改時用modify_mongo，儘管修改時的關聯線(Relationships)無法處理，但它能保持modify_mongo之前的所有關聯線(Relationships)。👍

AI協作資料庫圖表設計工具 - dbdiagram-oss

前言:

在接觸AI如claude-code和gemini-cli之後，注意到了和AI協作的特點，在協作的過程中，通常會需要把資料或資訊和AI互通，讓AI知道資訊，或者AI改了之後，讓我們知道AI更新了什麼或如何設計、修改的。
後端開發中，資料庫是很重要的部份，尤其是資料庫資料表與欄位設計，通常設計好資料表與欄位後，多半就開始刻API了，既然刻API都讓AI實做了，那資料庫的資料表、欄位也要和AI協作才會快速又清晰。
DBDiagram是一個非常方便的所見即所得(WYSIWYG)線上工具，透過DBML語法撰寫，就能即時顯示ER Model，讓資料庫的設計方便又清楚。
那麼DBDiagram是否有開源版？DBDiagram能否跟AI協作？
我以dbdiagram-oss為基礎用gemini-cli和claude-code學習Vibe-Coding，效果相當不錯。

成果:

整份專案在
https://gitlab.com/ycfunet/dbdiagram_oss

實做過程含花絮(😂😭):

它的後端是用熟悉的.NET Core c#開發，開發過程中就調提示詞的規格，讓它API使用EndPoint語法，但使用傳統Controller的命名風格。

MCP Server的部份，可能比較新，AI寫不太好，寫的不能動，我下去先看SDK用法之後，用範例改出一版乾淨版本之後，再讓AI參考這個乾淨版本寫，然後再新增MCP Tool和API呼叫，才OK。

它前端用的是Vue 3 + Quasar Framework，Quasar Framework比較小眾，原則上讓AI自己分析後先自己改，改著改著卡住，我讓它把程式碼位置先給我，讓它分析程式碼執行流程，然後我下去看了下邏輯後，跟它說錯誤點，再改後改出。

之後前端加功能，就讓AI自己新增了，都沒什麼問題。

一開始我用gemini-cli開發，之後改用claude-code。

gemini-cli比較幽默，我都跟它說：「去吧～阿斯拉～」，它會回答我「好的，全速前進」。

But...網路上的事情我也遇到過了，一開始註冊不懂，訂閱gemini-cli也設定API Key，我以為兩個都掛在我同個身份和訂閱上，我用API Key執行gemini-cli，gemini-pro 2.5用超爽，然後帳單噴了NT $14000多😱。

產出最多的2天，一天NT $8000多，一天NT $3000多😭。

然後，我就訂閱claude了。🤣

我對AI Coding的心得是，高階訂閱得付，AI的反應時間、Coding能力、程式碼的理解能力都明顯不同等級。

gemini-pro 2.5這種等級讓它看專案程式碼後修改，它如果看不懂或改不出來，那非claude、gemini的AI大概也沒辦法，一般常聽到350b、400b這種AI，實測Coding是無法的，可能context不夠長，可能不夠聰明，光是改個東西都很可能會繞圈，這也是為何claude、gemini都沒說它們背後運作的是多大的模型🤔。

微調Gemma3:270M用於FSM(有限狀態機) - 以貓砂機馬達控制Lab為例

 前言:

幾年前曾將家裡的貓砂機用樹莓派改裝，按照原本的控制邏輯用Python實做，並用於貓砂機控制。
在survey Gemma3:270M這種微型LLM時提到，Gemma3:270M具有很強的指令跟隨能力，貓砂機的馬達控制流程本質上就是FSM(有限狀態機)系統，而FSM的狀態處理本質上就是查表法，那麼，將Gemma3:270M的指令以「目前狀態」和「觸發IO」代入，生成「下個狀態」，不就能把Gemma3:270M應用在FSM(有限狀態機)系統，好像不錯，練習微調LLM，容易入門。

實做:

讓claude-code分析之前那個貓砂機程式，讓它把馬達控制的流程看懂，然後生成一個(FSM)有限狀態機的狀態表，接著讓它分析Gemma3:270 Finetune程式，程式內它的DataSet(資料集)用的是ChatML的格式，讓claude-code把馬達控制的狀態表轉成ChatML格式。

修改Gemma3:270 Finetune，將資料改用ChatML格式的DataSet，然後用colab執行，因為貓砂機的FSM狀態表不多，claude-code生出整個DataSet只有70條，整個微調訓練時間大概10分鐘即可完成。

成果:

用Ollama載入後，用固定格式問它，得出固定格式結果，如圖：

輸入「current_state: IDLE」「trigger_event: CMD_START_CLEAN」，
固定得出「next_state: STATE1_FORWARD」IO「in1_in1: 0, in2_in1: 1」。

整個Lab順利又快速，證明微調微型模型，可用於FSM(有限狀態機)的系統控制，測試時，幾次輸入，看起來結果一致性非常非常高(沒遇過結果錯誤的)。

程式碼:

https://gitlab.com/ycfunet/gemma3-270m_finetune-fsmsys

2025-01-01新年文～這幾年的前端之旅

這幾年斷斷續續學習網站前後端，一開始選型時，考慮到Java的基礎，因此看了GWT，後來發現目前的網頁生態已經全面以W3C以及Mozilla/Google/Microsoft/Apple為主的廠商和瀏覽器壟斷，基本上就是JavaScript方案主導了。

接著以不用前端框架 手把手打造基礎SPA為基礎，用TypeScript自己刻了一個SPA框架，並使用。

但改著改著，用著用著始終不順手，總覺得JS和TS語法寫著很彆扭，IDE的語法提示和程式碼樣式無法和自己的SPA框架適配。

近年Webassembly出現，想著是否能以WASM為基礎將SPA框架改成WASM，以便於開發，但發現支援WASM的程式語言支援度都不太好，尤其是和JS融合與DOM介接這兩塊。

於是看了c#的Blazor Webassembly，發現各方面整合都相當不錯，直接是Webassembly，整合JS和DOM都相當完整、穩定，提供純前端(Blazor Webassembly)和前後端(Blazor Server)方案，還能和.NET MAUI整合，直接做到了像是Capacitor這樣的Mobile的Web App開發方案和Electron這樣的電腦桌面的Web應用程式方案。

新年目標，將Blazor Webassembly學起來之後，實做一個Site Project。

金融自動系統

 前言：

2014年時，曾以Java為基礎開發了股市自動交易系統 - JavaATS，後來不了了之。
最近以先前的架構為基礎重新開發，系統改以Python語言為基礎，以PostgreSQL和MQTT通訊協定為核心，重新設計成開發式架構。
因為系統無法達成自動交易的目標，因此命名為金融自動排程系統。
這篇會描述系統架構。

系統架構：

系統延續JavaATS的排程器核心，以Python重新實做。
因為科技的進步，原先Configure Manager使用的XML現在直接改用ini + PostgreSQL，原本定義在XML內的Task，都改定義到SQL中。
原先各元件之間，透過一個Socket Server交換資訊，同樣因為科技的進步，現在直接透過MQTT就能達成，Socket Server交換資訊時的資料格式問題，現在透過json能夠方便的進行資料交換。

TimerServer：

這是整個系統的核心，它以Crontab語法為基礎，在SQL中定義多個Task，TimerServer會以while loop方式每15秒撈取一次SQL內的Task List，並比對當下時間和Task Crontab時間，符合就執行。
執行時，透過Python的os.system()，以及定義在SQL內的Task欄位，能夠指定直譯器以及程式參數，例如：
python3 Downloader.py
ts-node-script stock_invest_downloader.ts
python3 dir_scanner.py /tmp/data/

Crontab格式定義如下：

延續JavaATS的TimerServer，Crontab的語法基本上能做到特定日期時間執行、週期執行、每星期特定天執行。

多機跨網路系統：

TimerServer啟動時包括一個config.ini檔案，裡面定義了SQL的帳號、密碼、DB，一個稱為MY_RUNNER_NAME的名稱定義。
而在資料庫的Task List中，每個Task都包含一個runner的欄位，同樣的，TimerServer在檢查Task List時，會比對Task的runner和自己的MY_RUNNER_NAME是否一致，或者runner是否為空，如果為空或者一致，則進一步比對時間是否符合，符合則執行。
上述的runner設計，讓TimerServer變成了多機跨網路的系統，可在多台PC甚至樹莓派上執行，每台電腦都透過SQL撈取Task List，比對後判斷是否是相對應的機器和相對應的時間，符合就會執行，達到多機器跨網路運作。

圖形化管理元件：

Python支援Qt，在Blog以前的文章中寫過多次Qt文章，這裡緬懷良葛格，以前開發Qt程式時，良葛格是少數中文的Qt教學，而且不同於書籍和官方教材，他的文章內容精準，看得出是學過寫過得人，才寫得出的教學文章，可惜他竟然走了。
透過PySide2，能夠方便的新增、修改、刪除Task List的Task。

模組化元件：

只有TimerServer定時執行顯然不夠，要能建構出金融自動系統，至少還需要歷史資料、證券公司API行情程式、證券公司API下單程式。

以歷史資料而言，現在能夠過Yahoo Finance API的Python Package，直接撈取歷史資料，後續透過Python PostreSQL Package就能將資料寫入SQL中。
加密貨幣？
加密貨幣交易所也是有提供API的，NodeJS？
前面提到，TimerServer可透過指定直譯器執行，不一定是Python，當然也可以是NodeJS，如前面範例提到的，ts-node-script就蠻方便的。

證券API串接：

我使用的證券提供c#的API，原則上是PC的下單應用程式將Component拆出來，透過c#呼叫的，因此，Windows是必要的。
目前我開了一個Windows VM，用Visual Studio 2015的c#開發2隻程式，一隻為即時價格註冊和擷取程式，一隻為下單程式，證券公司的API中，即時價格擷取是一個API，下單是一個API。
因為以前的經驗，為了縮短開發時間，方便未來證券公司API程式改版。
我是以證券公司提供的範例程式直接修改，將視窗Dialog隱藏，增加右下角System Notify，然後加上config.ini、MQTT的相關程式碼。
作用，
即時價格擷取：
能透過config.ini、SQL撈取要註冊取得即時價格的Symbol，當取得即時價格後，透過MQTT發送。

即時下單程式：
透過MQTT取得下單指令，進行下單，並透過MQTT、LineBot回報委託情況。

上述2隻程式開發後，連同API一起放在一個Windows VM，並排程開機、關機。

資料分析與技術分析：

嗯～這是個大哉問，如果有答案就不會寫這篇了～啊～不是。
這個以TimerServer為基礎的系統，能夠方便的加上各種分析模塊，我們以典型的技術分析當作例子：
寫一隻Python程式，內容是
每日從SQL中撈取歷史資料，透過Python的TALib計算均線(Simple MA)，然後根據是否Cross，從MQTT或SQL上發出或寫入觸發信號。
當然，也可以是透過觸發信號直接透過MQTT發出下單指令。

來點更複雜的吧。
OK......

結論：

透過新版的金融自動(排程)系統，能夠透過開發各個模塊疊加，形成一個多功能跨網路的金融系統，因為以模塊化設計，各種功能都能實做，小到下載歷史資料，大到結合AI測試都能開展，而且透過SQL和MQTT，能夠讓各模塊交互作用。
TimerServer排程器是系統核心中的核心，所有的元件執行都透過TimerServer，透過runner欄位，能讓TimerServer做到多主機跨網路的能力。

BladeX(SpringCloud)介紹

前言

這一兩年因為工作需要接觸了基於BladeX的Spring Cloud，深刻體會到Spring Cloud的博大精深，因為這是中國公司以Spring Cloud集成的微服務架構系統，台灣知道的人比較少，這邊就介紹下這個大傢伙。

另外，前一篇介紹了我對JavaScript和NodeJS的看法，這篇也會帶入，既然NodeJS這麼好，BladeX適用情境在哪？

BladeX介紹

BladeX是由上海布雷德科技有限公司集成的Spring Cloud解決方案，產品稱為BladeX。

BladeX包括開源版和商業版，不用懷疑，大家都用商業版，開源版基本上只用做入門，事實上以商業版而言，它的價格不算貴，商業版授權大概台幣30,000左右，無使用限制、無授權期限制、無升級版本限制，基本上就是買一次，無限使用。

BladeX有2個版本，BladeX和BladeX Boot，兩個版本分別對應Spring Cloud和Spring Boot。

使用上，大部分使用者都使用BladeX，BladeX Boot版本用的人很少很少。

BladeX系統需求

BladeX的架構是所謂的微服務2.0。

BladeX要佈署和運行，至少需要 MySQL、Nacos、Redis，其系統需求，除去MySQL、Redis、Nacos這3台伺服器外，通常還需要3台每台至少8GB(建議16GB)記憶體的伺服器。

上述意思是，BladeX的運作環境，伺服器需求6台起跳。

Spring Cloud與BladeX架構介紹

以Web Service觀點看Spring Cloud，Spring Cloud是目前Web後端微服務2.0架構的主流。

以前以SOAP Protocol為基礎的Java 2 Enterprise Edition (J2EE)，目前都改以Spring架構實做。

單從Protocol觀點而言，J2EE使用SOAP為基礎，SOAP以RPC + HTTP + XML組成，Spring則以(WebSocket) + REST API + HTTP + json組成。

既然對比的是J2EE，Spring Cloud的特點是在高穩定、模塊化、大架構、分散式的企業級應用情境。

Spring Cloud由許多輕量級組件組合而成，我們從下面這個架構圖看起：

來源：https://www.cnblogs.com/Irving/p/7598883.html

這張架構圖算是比較簡潔的圖，先以這張圖描述服務註冊(Service Register)和服務發現(Service Discovery)。

Spring Cloud的架構中，以服務註冊(Service Register)和服務發現(Service Discovery)為基礎，在Spring Cloud中，一般用Eureka (BladeX中是Nacos)。

所謂的服務註冊(Service Register)，是系統中所有要運行的微服務，在加入系統時，都要先透過Eureka進行註冊(Service Register)，服務註冊後，系統內要呼叫和使用服務時，都可以透過Eureka的服務發現(Service Discovery)，自動的找出相對應服務的微服務。

例如：

上圖中右側有個Auth Service，是使用者認證用的，要在上圖系統中使用Auth Service

首先，要先在Eureka (BladeX是Nacos)中先註冊Auth Service

使用時，要使用的程式要先詢問Eureka (BladeX是Nacos)，Auth Service是誰？Eureka (BladeX是Nacos)會將Auth Service的IP和Port回傳給要使用的程式。

這個註冊和使用過程看起來有點複雜，在Spring Cloud中，呼叫、查詢和使用封裝在Feign Client API當中，透過呼叫和使用Feign Client API，它底層直接將上述行為處理完成。

在寫程式時，我們會需要全域變數紀錄和處理環境變數，並讓系統內所有程式都能存取，同樣的，Spring Cloud的微服務也需要存取共用的變數資料，在Spring Cloud中，並不將它稱為變數，而將它稱為Config或設置參數。

因為這些Config需要能夠共用，因此這些Config需要特定一個服務儲存和管理，它就是上述架構途中的Spring Cloud Config(BladeX中是Nacos)。

系統內所有的微服務，都能夠透過存取Spring Cloud Config(BladeX是Nacos)，儲存和讀取Config。

例如：

微服務要能存取MySQL，通常會將MySQL的JDBC URL存放在Spring Cloud Config(BladeX是Nacos)，使用時取出。

前面提到過，BladeX是Spring Cloud集成的解決方案，在BladeX當中，上述的服務註冊(Service Register)、服務發現(Service Discovery)和Config參數管理，都是透過Nacos管理的，而Nacos是阿里巴巴針對Spring Cloud開發的輕量級服務。

Spring Cloud中包含很多微服務，實際使用時，Client端通常不會直接存取微服務，Client端一般會透過Spring Cloud的API Gateway存取，在Spring Cloud中是ZUUL，而在BladeX中，它包含了一個稱為bladex gateway的微服務。

架構圖如下：

來源：https://exampledriven.wordpress.com/2016/07/06/spring-cloud-zuul-example/

BladeX的bladex gateway和ZUUL作用相同。

所有Client都存取API Gateway，ZUUL和其他微服務的需求，則透過Feign Client API互相存取，中間存取的API，都是REST API，資料格式都是json。

BladeX(Spring Cloud)與php/express/django比較

典型的Web應用，通常由SQL(常見MySQL)、Apache、Web Backend、Web Frontend組成。

通常SQL一台，Apache和Web Backend一台，其他Client端都在系統外部。

這樣的應用，一般使用php/nodejs express/python django都能方便開發，經典的CRUD這類都足夠並方便使用，我自己估計，大概9成的應用都屬於此。

BladeX與Spring Cloud適用在企業的大型Web應用，它最基本需要穩定，還需要模組化，能夠以模組形式開發新服務，還需要具備分散式系統的橫向擴充性。

例如：

當希望有多個Client入口分散系統負載時，直接開多個API Gateway即可，只要確定Nacos內API Gateway有多個Instance，就能橫向擴展服務。

上述這些需求，會讓系統架構的複雜度變高，比較不適合直接用php/express/django開發，底層需要的API和SDK太多太雜。

舉個例子：

Nacos有NodeJS的API，透過呼叫Nacos API，NodeJS也能做到服務發現、服務註冊、Config存取，但這個只是Nacos API，並不是Feign Client API，實際在開發微服務時，需要大量使用Feign Client API存取其他微服務，光是要把NodeJS Nacos API包裝成Feign Client API，就要花費很多時間成本，而在BladeX中，Feign Client API只是其中一組常用的API，其他像是資料庫ORM的MyBatis API、加解密API...等，大概有10幾組API，不大可能全部用NodeJS重造輪子。

結論

BladeX是博大精深的微服務Web Framework，它集成了認證、會員管理、後台管理界面...等功能，它的系統集成了以Nacos為基礎的許多輕量級Spring Cloud組件服務，且能夠擴展支援包括Prometheus...等監控系統服務，承襲Spring Cloud的架構、模組化設計、橫向擴充能力、服務管理...等特點，讓大型Web應用的開發變得容易。

同時，BladeX與Spring Cloud這類Web Framework的設計目標，並不是使用在常見的小型Web應用，如果開發的目標項目是一般會員網站或功能網站，系統需求鎖定在2台以下的Web Server時，以express/django開發可能更為簡單方便。

(圖與排版後續補上)

JavaScript/NodeJS Web前端之我見

前言

這一兩年因為工作需要接觸了JavaScript/NodeJS與Web前端，也因此對所謂的Web前端有了更深刻的體會和理解。

這篇文章雖然標題寫的是JavaScript介紹，但後面會描述JavaScript和Web前端的不可替代性。

Web前後端概念

早期的Web並沒有區分前後端，典型的開發方式是先做個Web版型，然後Web內容替換asp/php/jsp寫的function和變數，瀏覽器載入時，Server會執行這些function，並將執行結果放入Web中提供給瀏覽器。

目前的Web開發，則多半會建議前後端分離，所謂的前後端分離，指的是後端一樣是asp/php/jsp，現在甚至可以是NodeJS Express/Python Django。

後端開發後，提供的是所謂的RESTFul API，一般簡稱REST API或API。

前端開發，則幾乎都是以JavaScript/TypeScript為主的Web App。

為什麼分成前後端？有沒有必要？能不能不學JavaScript/TypeScript而用Java/Python/C++開發？

這是我在接觸Web前端時的一系列疑問，而後得到了答案。

1. 為什麼分成前後端？有沒有必要？

Google多半會查到，現在的趨勢如此，專業分工，前後端架構...等，但WordPress沒有前後端分離，一樣有很大的使用群，那需求和原因在哪？

其實最關鍵的需求和原因，是多平台支援。

現在這個時代，手機佔了很大的使用群，手機又區分了Apple和Android，Apple要使用ObjectC/Swift開發，Android要使用Java/Kotlin開發，而傳統的PC和Web要支援嗎？PC可能要用c#開發，Web要使用JS開發。

為了能夠滿足多平台開發，典型前後端一體的開發方式，無法適用在這樣的情境中，因此，將後端改為REST API，前端各自使用HTTP API串接成了解決方案，而這點，才是前後端分離開發的真正原因。

換句話說，假設今天明確的需求是，我們只使用Web瀏覽器，並且不打算支援手機，那麼是否要前後端分離其實沒這麼重要。

2. 能不能不學JavaScript/TypeScript而用Java/Python/C++開發？

這個問題，很多後端想跨入前端開發的都會問，我一開始也是如此，事實上這有好處。

想想看，團隊成員都會Java，直接用Java開發前後端，人力能自由調配，這是很大的優勢。

但實際上呢？答案是不太行，原因很簡單。

目前所有的Web瀏覽器，核心都是JavaScript Engine，而目前Web瀏覽器，尤其是Chrome，基本上跨所有作業系統平台，Chrome地位等同以前的IE，幾乎是Web瀏覽器的代名詞，因為它原生支援的是JavaScript Engine，學習JavaScript這件事就避免不了。

那TypeScript和其他語言又如何呢？

目前TypeScript和其他語言，都是透過轉譯器的方式，將程式碼轉譯成JS後，在提供給Web瀏覽器執行的。

Web前端優勢

我們先帶個比較無關的東西，看一看Google AI的TensorFlow SDK"主要"支援哪些語言？

TensorFlow API Document

TensorFlow SDK支援4種語言，包括：

Python/JavaScript/C++/Java

其中有趣的是，Java點進去會發現，它都寫這個支援未來可能移除。

Python因為簡單易學，是目前的顯學，學校教的程式語言，都開始改教Python，以AI主軸在類神經網路設計/訓練/推論這幾個開發點，程式語言帶出的系統架構不是重點，程式執行速度也不是重點，簡單實做和修改類神經網路才是重點，因此以Python為主要語言是合理的。

C++的優勢除了程式執行速度快，上至伺服器服務和Web後端，下至MCU都能支援，最重要的是，C++編譯後，Binary反組譯比較難，原始程式碼隱蔽性好，是主要語言合理。

Java在程式語言開發中，仍舊有非常高的使用率，因此支援Java不意外，但它的開發便利性不如Python，程式碼沒有隱蔽性，不如C++，因此有支援但可能移除就不意外了。

那JavaScript為什麼變成主要支援的語言？

簡單的說，目前所有Web瀏覽器都只支援JavaScript，而目前所有作業系統平台都有Web瀏覽器，支援JavaScript，等於能讓AI應用從PC到手機全部支援。

意思是，JavaScript與Web瀏覽器，原生就具備跨平台能力，儘管在不同平台上的整合度沒有各平台原生語言強，但套用Java以前的標語：One language run anywhere 完全沒問題。

JavaScript與分散式特性

傳統系統開發時，為了最大化系統效能，通常會測試系統可支持的最大負載量，然後將最大負載量設為80%左右。

一般而言，不論是PC/IPC/開發板，效能越強單價越高，通常都希望盡可能的降低程式CPU和記憶體的使用量，拉高系統可負載量。

當我們代入Web前後端開發後，上述的最大負載量能直覺反應，它是屬於Web後端的服務，那前端呢？

Web前端通常運作在Web瀏覽器中，因此JavaScript和Web瀏覽器執行在Client端。

一個極端的說法，對於Web前端而言，後端只需要有個Web Server提供儲存空間，能讓Web瀏覽器下載HTML和JS，後續就能在Client端的瀏覽器中執行。

從這個觀點看JavaScript和Web前端，它是完美的分散式架構，所有程式都分散運行在全部的Client當中，不會佔用後端Server服務資源。

白話的說，如果盡可能在Web前端用JS開發和執行，能最大程度降低後端服務器的負載量，增加整個系統的使用效率。

而目前Web瀏覽器和JS SDK能夠支援的運算越來越多，已不是傳統的JS function只處理頁面顯示，像是TensorFlow能夠直接用Web瀏覽器在本地執行Ai程式，WebGL能夠直接在Web瀏覽器繪圖，瀏覽器內嵌的影片播放器能夠直接播放影片並進行H264/H265...等影像格式解碼，以往這些負載較大的程式，現在都能轉到Web前端運行，以分散式觀點而言，能很大程度的降低後端負載，增加系統負載量。

Web3.0與區塊鍊

區塊鍊細節這裡不提，一方面熟悉度沒這麼高，一方面是要描述Web3.0與分散式發展的觀點。

前面提到，從Web前後端觀點看JavaScript和Web瀏覽器的應用，JavaScript和Web形成了完美的分散式架構，有沒有一種可能，讓全部的Web瀏覽器之間互相連線，運行同一支JavaScript程式，變成一個全分散的執行環境和系統？

我認為，Web3.0提出的區塊鍊就是答案。

我們把記憶回到以前的P2P，包括eDonkey和BT，並以eDonkey設計思考。

eDonkey這類P2P的典型設計如下：

所有P2P Client都有檔案清單，所有資源都在P2P Client，eDonkey Server處理的，是紀錄和提供P2P Client的IP列表。

P2P Client啟動後，先連上eDonkey Server詢問最新的P2P Client列表，再跟自己的P2P Client列表比對，接著根據上傳或下載提供檔案(資源)清單，接著進行檔案(資源)上傳和下載。

Server主要服務是維護P2P Client清單。

BT則進一步透過DHT，讓P2P Client之間能夠互相連線取得這份清單，進一步降低Server的依賴性。

那麼，有沒有可能這樣的設計用JavaScript開發在Web瀏覽器上面執行？

我認為區塊鍊是這樣設計的變形。

典型的區塊鍊，每個Client(錢包)都以token形式表示，Client(錢包)中每個代幣(資源)也都以token表示，每個所謂的主鍊(P2P Network)，所有的代幣(資源)都以linklist的形式串接，新的代幣(資源)要加入到主鍊(P2P Network)，需要主鍊上超過一半以上的Client認可後，串入其中。

會發現，Server在其中的角色和傳統P2P網路的Server有一點相似，Server所謂的交易處理，可看做傳統P2P網路中，新增檔案(資源)時，通知各個P2P Client，進行資源清單同步的動作。

當然，在區塊鍊下，區塊鍊的Server的服務更多，區塊鍊錢包的功能是以錢包為主，沒有所謂的資源，但如果以P2P和Web瀏覽器的分散性思考，比較能夠體會坊間將區塊鍊介紹為Web3.0的原因。

結論

JavaScript從一開始就是Web瀏覽器主要的執行引擎，在目前的Web開發中，具有Web瀏覽器執行的不可取代性。

因為Web的普及，Web瀏覽器是很重要的跨平台環境，這讓JavaScript具有特殊性。

又因為Web瀏覽器是在Client端作業系統中運行，讓JavaScript具有分散性。

以前Java所謂的One language run anywhere，現在的作業系統中，Windows Linux PC預設都沒有Java，Apple iOS也沒有Java，只有Android還以JavaVM為基礎。

但看看現在的Web瀏覽器，PC/Android/Apple iOS，每個平台都有，JavaScript在這個時代成為了One language run anywhere的代表。

以此為基礎，NodeJS可單獨執行，並且有Express這樣的Framework，這讓JavaScript從Web瀏覽器前端跨入伺服器後端服務程式，回想一開始期望的，假如團隊中都是Java開發者，前端到後端都使用Java開發，人力調配的便利性，如果Java改成JavaScript和NodeJS呢？

(圖和排版後續補上)