2025年9月30日 星期二

最近AI圈很火的chrome devtools mcp

 

洨邊假設大家知道mcp是什麼了,直接上官方github,文件寫得很清楚

https://github.com/ChromeDevTools/chrome-devtools-mcp

這邊以codex為例

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

基本上就裝好了

接著就來實際操作一下

我們來切一個figma版

首先把下面選項選到箭頭,第二步選擇頁面的標題按右鍵,找到copy as > copy link to selection,複製這個頁面的網址(取得node_id)



咒語:
使用chrome devtools訪問figma中設計好的頁面,用tailwindcss完整的復現這頁面:{網址}
然後你就靜靜看著他完成吧
這個token吃挺兇的

9/30
第一次嘗試,大失敗,他完全沒有參考我給的figma自己亂切東西,還吃了我一大堆token....

2025年9月12日 星期五

HD鬼故事N+5集

今天來說說洨邊的主管之路

就在洨編當上主管後,PM照常發任務給我底下工程師,我就這樣被架空了半年,甚至連週報都沒有寄了,每天就忙著摸摸新技術什麼的,甚至還抽空學了套flutter,過得好不愜意。

就在半年之後,因為人力分配不當導致專案延宕(事實上我覺得分配沒啥問題,畢竟我底下也才兩個人可以用),老闆怪罪下來,說項目經理(CEO)管理不當,再犯直接辭退,PM架空主管,懲處罰金X千元.....WTF,如果是我,寧願被口頭警告也不要被罰錢,而且公司可以罰員工錢的嗎!!這啥鬼故事!

但這事也沒什麼,就在事情過去兩三個月,我終於把手邊任務清得差不的時候,團隊迎來第一個大任務,重構

就是手上有五個長得非常類似的站,當初不知道哪個白癡手筆,硬拆成六個專案來維護(一個基礎站,別問我這是什麼,解釋起來我會怕),我從進公司就不斷提說要節省人力,要好維護,要不出問題,終就只有重構一途,這次終於要進行了

隨著會議進行,雖然項目很大,但我也是摩拳擦掌,信誓旦旦,沒想到在老PM休假一週後,一切就變天了,在一次會議中

老闆:還是你就在五個站當中挑一個站,加上換膚,這樣不就可以了

我:????(那我們前兩個禮拜在討論辛酸的嗎)

但老闆都說話了,且這筆買賣我也不是太虧,我就挑一個我有長期在維護跟重構的專案來當基礎站

我:那我選76站

老闆:那你們要解決頁面切換不順暢的問題

我看到這句話,心理想說我都已經沒有用lazy load,還會切換不順??難道要加上動畫??

所以我拆成兩大任務進行,第一,我現有的react專案,把底層改成astro.js(網傳這樣切換速度可以加速),路由切換加上動畫。第二,加上換膚功能

第一任務簡單說就是,在置換過程千瘡百孔,動不動就沒畫面,一堆坑要填,免勉強強一個月才完成底層置換,根本不像網路上講的幾乎無腦置換,重點換完效能更差==每次頁面切換都會頓個半秒到一秒

第二個任務倒是很快就順利完成

最終到了驗收時間

老闆:你們沒有解決畫面切換不順的問題啊,我不能為了節省人力,讓客戶體驗變差,公司為了你們一個月沒有任何產出

我:當初讓我選的是你,答應的也是你,現在不讓我上的也是你,且這專案頁面切換幾乎就是0.1秒,到底哪裡不順,能不能說明一下

CEO:你看一下錄影

我看完錄影發現,畫面是切過去了,但component要等api打完,才會長出來,幹!這叫做顯示流程有問題,才不是什麼效能問題

我看完真的是無FUCK說,需求在他們心裡,在這公司也不是一天兩天的事,PM私下建議我不要再上訴,默默把顯示流程優化完,再給他們看,簡單來說就是要我們加班拉。

然後過兩天......這位PM就掰了......說是沒過試用,實際原因也不知道,我也只能猜他背了我們的鍋。

過幾天老闆鬆口說,這次真的要進行重構了,但需要作足研究,避免做出來更慢(看來他對我們誤會很深啊),然後要我們給承諾.......(這公司不僅會扣錢還要員工給承諾),我說技術就這幾種,你們在意的體驗問題我們也了解了,新的站會特別打磨這塊,針對競品的研究可以作給你,但承諾我是給不出來拉,畢竟關係的層面太廣,從運營到後端,每個環節都可能影響網頁流暢,不能所有事都我們扛吧!

這次雖然真正開始重構,但老闆也沒上什麼心,但這樣也好拉,省的他來比手畫腳==,且畢竟之前停擺了一個月,累積了大量的卡片要清,所以我也只能讓大家先把任務做完,有空在進行重構,只是可想而知這樣進度一定會不如預期,但....目前也只能這樣

真正的鬼故事才正要開始,一次機緣下,其他部門要招新人,老闆隨口提到看我要不要再找一位,(其他部門有一位前端因為開週會時,開直播逛賣場後來掰了),我想說員工這種事多多益善,隨口就答應了,隨即談起這次照聘薪資,我聽聞後,寫信給老闆說:如果只是要補這工程師的洞,根本不需要這麼多錢,故能否招聘個普通的工程師(我有內推),然後剩餘金錢讓我們作其他應用,幫其他員工加薪

老闆馬上斥責我,公司沒有加薪制度,且你最近表現不佳,部門屢屢犯錯,破壞公司和諧,已經準備找人取代你!

......對於沒有完成換膚,我只能說,我確實也沒確認好他們的需求(幹這是PM的工作為啥是我扛)。過程中員工犯錯,我也不能為其說話,這就專案就的確實有問題,你就算殺了他也解決不了事情,事情還是會一再發生。最後對於破壞公司和諧的部分.....我只能說,那天我口氣確實不佳,但我始終就事論事,論述內容也沒問題,是對方開始跳針,且當時已經很晚了。但說到底這也是我跟那員工之間的事,這也要被他捅刀上報,我也是認了。重點這是都過去兩個月了,還要拿出來鞭屍。

我完爾一笑,日後也只能龜縮度日,但招募還是要繼續

就在七月中,我面識了一位內推,技術能力不錯,開發習慣也不錯,重點他還是台中人,且暫時沒有其他競爭者,我回報給PM結果,想說應該是穩了,沒想到過兩天PM回復:老闆希望找個有領導經驗的......你他媽的!有先決條件怎麼不先說!目的這麼明顯要把我換掉你幹嘛不自己來面啊!讓我面一個人來把我換掉,你可以在惡趣味一點啊!~

結果過了一個多月的奮戰,這位仁兄還是沒能錄取,錄取了另一個技術能力不錯,話非常多的工程師,有機會在來說說的的故事

總之我在這間公司的故事還沒說完,看有沒有機會出第六集~

10/7 沒想到這麼快就更新了,篇幅不長,究沒有出第六集,改DLC的方式新增

前情提要一下,目前公司有個主要業務,「五站(76+4站)」要維護,還有一切其他組業務,但不是今天重點,重點是公司目前主力開發「重構站」這個產品,目前重構站以從七月底開始開發,技術使用vue3,開發至今也才兩個多月,當初開給公司的工時是半年,遊說時間是兩年,然後目前前端組有以下工程師:
我(資深工程師兼主管,負責重構站)
A(資深工程師,負責重構站)
B(資深工程師,負責76站)
C(資深工程師,負責4站)
D(資深工程師,新進大能,原本我要讓他支援另外一組的任務+本組打游擊,讓他多方熟悉業務)
E(初階工程師,負責另外一個組的專案,偶爾來支援重構)

記得這些前提

這位新進大能入職後,因為他不熟vue熟悉react,而且重構站功能已經完成大半,我自然把他安排去維護76站。然而才過了短短一週,我已經收到兩次命令,希望他能投入重構站的開發任務,第一次被我以業務不熟,語言不熟,功能大致上已完成駁回,第二次在收到命令,我知道這次無論如何無法在駁回了,也只能接受。

接著D打電話來說:「他們覺得你辦事不力,很多東西都沒有達到當初協議的水平,UI敏感度不足,當初開的時是四個月....八拉八拉」,總之上頭希望D主導重構,但D回絕

四個月.....當初明明就說六個月,我都懷疑我講的中文跟上頭學的的中文意思是不是不一樣,他們才一該去參加中文怪物吧.....過程聽得出來他很理解工程師開發流程,也極力在幫我說話,主要先把功能做出來,再做細部優化,作一個好的作品根本不可能一步到位,做夢除外。我聽完也只是隨口抱怨兩句,沒多說什麼。然而真正讓我炸膛的是接下來要發生的事

在下班前,第二道命令接踵而來:「把B工程師也調去寫重構」

....B被調去寫重構,那76站怎麼辦?凡是會一點算數的都算得出來,扣除初階工程師,C本身就有4站要顧也無暇抽身,我手上能用的也只剩下A工程師,但這樣不對啊,A本來就負責重構站,現在功能都開發完了,大多都在測試跟debug階段,那不就等於要把最熟悉的人調離!!

於是我反問:「那是要我把A調去寫76的意思嗎?」我思來想去又補問一句:「還是上頭希望我去76站?」

PM回復我:「你覺得怎樣對重構站影響最小就怎麼做?」

此刻我明白了,我又再次被架空,根本沒打算讓我調度人力,而且根本沒打算尊重我,竟然真的把我跟A一同放在選項中,先說我從來不覺得主管不能coding,但我覺得主管不應該被任務綁死?而且這根本不是我過去或A過去的問題,我們兩個都有各自負責的功能,大多任務也都進入測試階段,不管是我去或他去,都代表有人要來擦我們的屁股,然後把兩個最熟悉架構的工程師調離,換兩個不熟悉的人進來,用馬的眼睛想都會知道,不管怎麼選影響都超~大~!

但~算了,我現在只是一般快樂小職員,可以準時下班我就偷笑了,這麼複雜的事我不想管也管不動了,大家晚安!祝大家中秋節快樂~

2025年9月11日 星期四

vue3做css變數操作除了v-bind你還有其他選擇(好文分享)

話不多說,上連結

簡單說靠著ref指定元件,接著設定:root css變數,最後靠setProperty改變變數內容,這著挺精妙的,大家有空可以上去爬原文



2025年8月8日 星期五

靜態資源快取怎麼做?

前言

很難得一天發兩篇文,還都不是我的本業文(算了我也不是第一天不務正業

總之後端反應為什麼前端會重複下載靜態資源,請我去查(乾~這又關前端什麼事

我再度拿我的專案去問gemini-cli,他給我的檢查方式是看network,靜態資源檔的size,如果顯示為disk cache或memory cache,那就是正常快取,如果為容量,那就是沒有快取(我以為是看status301,問了才知道301是轉址,好在不是問維運不然一定被嗆爆

這邊有個要注意的點,注意network頁的disabled cache不要打勾,不然你永遠看不到快取(我就這樣犯傻浪費了些時間

以下這張圖就是有拿到快取


假設沒有快取,如果你想在nginx上設置,可以加上以下配置,時間可以自訂

location ~* \.(jpg|jpeg|gif|png|svg|ico|webp)$ {
# 快取有效期設為一天
expires 1d;
# 明確設定 Cache-Control 標頭
# public: 可被任何快取(包括 CDN 和代理伺服器)快取
# immutable: 告訴瀏覽器這個檔案內容絕對不會改變,不需要為了驗證而重新發送請求
add_header Cache-Control "public, max-age=86400, immutable";
# 可選:關閉這個 location 的存取日誌,減少 I/O
access_log off;
}

這樣應該就可以做到一天快取

小結

結果在我們站上,我把nginx設定拉掉,快取還是在啊,強烈懷疑那位後端把disabled cache打溝了,但我沒有證據......好拉快點讓我下班吧==

2025年8月7日 星期四

原來前端資源讀取阻塞是Http協議的問題

前言


圖片有點小,簡而言之他們說api載入速度慢是因為前面一堆東西要載阻塞了,請前端協助確認

原來loading組塞也規前端管,三更半夜收到這種消息想必正常人都要睡不好了!

好在我11點就調勿擾,且我已經睡了。珍惜生命,遠離手機,特別是三更半夜還有同事在加班的公司。

總之言歸正傳,我之前一直以為瀏覽器的升級讓資源載入不會阻塞,所以我壓根不用考慮這件事,所以我問一下ai獲得以下答案


A:1. (強烈建議) 啟用 HTTP/2 或 HTTP/3
這是解決此問題最現代、最有效的方法。
* 原理:HTTP/2 和 HTTP/3 支援「多路復用 (Multiplexing)」,允許在單一的 TCP 連線上同時處理多個請求,完全繞過了 HTTP/1.1 的隊頭阻塞 (Head-of-line blocking) 問題。
* 如何做:這需要在伺服器端進行設定。您需要與後端或維運團隊合作,在您的 Web 伺服器(如 Nginx, Apache)或 CDN 服務商上為 api.ktkdf.xyz (或 bb.025674.com) 域名啟用 HTTP/2 或 HTTP/3
支援。
* 優點:一勞永逸,不僅解決 Stalled 問題,還能提升整體網站的載入效能和反應速度。

Q:接著我問我該如何得知目走的是HTTP多少

A:方法一:使用瀏覽器開發者工具 (最推薦)
這是在您自己的開發或生產環境中,最快也最準確的確認方式。
1. 打開您的網站:在 Chrome、Edge 或 Firefox 中打開您要檢測的頁面。
2. 打開開發者工具:
* 在 Windows/Linux 上按 F12 或 Ctrl+Shift+I。
* 在 macOS 上按 Cmd+Opt+I。
3. 切換到 Network (網路) 標籤:在開發者工具面板中,點擊 "Network""網路"
4. 重新整理頁面:保持開發者工具開啟,然後按 Ctrl+R 或 Cmd+R 重新載入頁面。你會看到所有的網路請求都列了出來。
5. 查看 Protocol (通訊協定) 欄位:
在請求列表的表頭中,找到名為 "Protocol" 的欄位。
* 如果沒有看到 "Protocol" 欄位:在表頭(例如 "Name", "Status", "Type" 的那一行)上按一下右鍵,然後在彈出的選單中勾選 "Protocol"
6. 判讀結果:
* 如果顯示為 `h2` 或 `http/2`,恭喜,您的網站正在使用 HTTP/2。
* 如果顯示為 `h3`,代表正在使用 HTTP/3 (更新、更快)。
* 如果顯示為 `http/1.1`,則代表您還在使用舊的 HTTP/1.1,這就是造成 Stalled 問題的元兇。

方法三:使用 curl 指令 (進階)
如果您熟悉使用終端機,可以用 curl 指令來檢查。
打開您的終端機並執行以下指令 (將 your-website.com 換成您的域名):
1 curl -Is https://your-website.com | head -n 1
* 如果回應是 HTTP/1.1 200 OK,代表是 HTTP/1.1。
* 如果回應是 HTTP/2 200,代表是 HTTP/2。

檢查結果


方法二要用工具太麻煩就忽略吧

至於http protocol之間差異在哪,gemini解釋太長了我直接放上連結

用人話來說就是http1.1一次只能載6個檔案,所以會組塞,http2跟3速度更快


小結

所以最終結論就是,真的不關我的事,後端跟維運要處理,AI萬歲,半小時搞定,準時下班~



2025年7月23日 星期三

你知道vscode也可以做到ngrok的效果嗎?

通常我們要把電腦的網頁分享給別人

一般人都會下指令

ngrok http 80 // or 8080 or ....

前提是你有ngrok指令,這樣就會產生一段網址,可以連到你電腦的某個port

但近期看到一篇奶綠茶大大的文章

詳情大家可以自己去看,簡單來說vscode也有類似的功能,但實際操作起來狀況挺多的,我作一下紀錄

我初次在嘗試一直卡在開啟的部分(我現在試正常,可惡,而且似乎只有我遇到),等了十分鐘也沒下文,我想說不應該啊,一個服務啟動這麼久,好意思說要取代人家,後來show log點進去,滑到最上面,有看到一些網址,找到device後綴那個網址,先別急著點,再往後面一點,有一串八碼的代碼,先複製起來,再打開該網址

首先會看到要用github帳號繼續,接著會要求輸入八碼代碼,然後就是認證什麼的繼續點,最後才成功開啟服務,看到他給的網址

記得把port visibility改成public,修改方式是按右鍵,找到port visibility,下拉選單進行選擇(這點實在很不直覺),這樣可以讓你朋友在連網址可以少一個動作,但還是有機率會先進到微軟畫面,要點一下繼續(這情況大概兩三個人會遇到一個,我拿學生作實驗)

結論:
所以論爽度ngrok還是稍爽一些