[ 首頁 / 搜尋 / 管理Discord ] [ Komica首頁 ] [ 跨版面 ] [ 雜談 / 車 / 攝影 / 運動 ] [ 人工智慧 / 程設交流 ] [ 蔚藍檔案 / 英雄聯盟 / 米哈遊 / Minecraft / 魔物獵人 / 勝利女神：妮姬 / Pokémon / 刀劍亂舞 / Unlight ]

/cs/ - 程設交流

Computer science
[]
名稱
Email
主題
回覆
檔案
嵌入
Options
密碼 （用來刪除檔案。）
  • Allowed file types:jpg, jpeg, png, gif, mp4, webm
  • Max filesize is 10 MB.
  • Max image dimensions are 10000 x 10000.
  • You may upload 1 per post.

  [Go to bottom]  [Catalog]  [Reload]  [Archive]  [Featured]

File: 1743525312173.jpg (1.31 MB, 4000x2668, wallhaven-nrkyl7.jpg)

fb745441 No.337[回覆]

被Vue的Datatable氣到，一個inline-editor居然弄不出來。
明明都弄成Compoenent了…
估狗+問AI搞了半天也想不出怎麼樣把Editor跟Datatable Compoenent合體。

氣死人，最後自己用 v-for + v-if 硬幹了。
是引進最新型的框架：香草JS的時候啦(做夢吧你

https://kknews.cc/zh-tw/code/3qjg2ag.html

每次看到這些東西都覺得前端真的走錯方向到很歡樂的地步。
公司+客戶都說要用Vue我也沒辦法，不過比較好奇現在世界上還
存在能夠只靠VanillaJS + HTML + CSS 弄出現代網站的前端工程師嗎？
又，如果發案的時候堅持這個組合，會需要付出更高的金額嗎？
另外是，這樣子設計的網站，有辦法維持相同的維護性嗎？
維護姓老實說是目前不依賴框架很難達到的地方。
1 則貼文 已省略。點擊回覆以查看

1bb3a439 No.355

>>344

的確是滿離譜的，你接觸到的應該是NodeJS那類純後端吧。
這邊講的 React / Vue 之類前端框架主要目的就是把
「產生HTML」這件事情搬到前端來。
前後端之間的溝通只傳送資料，不傳送HTML，
HTML的部分由前端網頁在收到資料之後產生。
除此之外還可以做雙向綁定之類的。

前端框架比較矛盾的一點是在於這其實算是一種發展結果，
即使今天你限定你自己只准用 VanillaJS，
但是相關功能架一架之後為了重複運用一定會做某種程度的框架畫，
於是一個新的 OO.JS 就這樣誕生了。
雖然可能沒有 V/A/R 那麼複雜，但最終還會走上一樣的道路，
然後功能性還遠遠不及。
貼文太長了。點這裡查看全文。

885fe6cf No.357

如果只是簡單靜態網頁的話那當然沒什麼問題
但如果你是作那種互動性比較高的網站的話那還是用framework比較好
不然光處理reactive就會搞死你了
至於framework的話我目前是用svelte
它使用起來的體驗跟其它framework比起來算是比較接近vanilla了

885fe6cf No.360

>>355
前端發展會那麼扭曲歸根究底就出在web standard上
web standard限制你只能用html+css+js來做web開發
而這三個語言又被限制要能夠完整向下相容不能有breaking change
搞得一堆初期的爛設計沒辦法捨棄掉
然後功能追加又要一審再審進度夭壽慢
所以才會有一堆framework冒出來就是想要突破這些限制
現在只能寄望wasm發展起來後能夠改善這扭曲的環境吧

23cc0c03 No.361

>>357

這老實說也是目前Vanilla派遇到的最大技術難點，
目前看起來也沒有甚麼現成的方法論可以用所以VanillaJS一直停在嘴砲或是半玩梗的階段。
就像樓下 No.360 說的，問題是出在Web Standard上，
可以說能弄出Standard就已經是很厲害的一件事情了。

>>360

Web Standard 的影響我覺得沒那麼大，

真的有問題的其實是心態，很多人都以為前端很簡單，然後發現不簡單之後就開始試圖把事情弄簡單(然後就是現在這慘況…
前端其實一點都不簡單，只是好接觸不用先裝一大堆東西(阿現在要了)，光是要理解HTML的ML(Markup Language)具體是甚麼就不是一件簡單的事情，更遑論去在標準框架內做變化。
CSS 雖然以不直接操作記憶體而言的確是高階語言，但實際上住海邊，根本可以說是把繪圖器七八成的變數都開出來給你改的程度。
JS 則是最痛苦的，因為被丟進來的我往都是連小白都不到的素人，還會被騙說這是一片白紙，才怪，
貼文太長了。點這裡查看全文。

23cc0c03 No.362

>>但如果你是作那種互動性比較高的網站的話那還是用framework比較好
>>不然光處理reactive就會搞死你了

對，所以現在還是只能乖乖用框架，本公司是新專案被客戶逼著用Vue。
編輯方便性真的沒話說。

這種個人信仰的東西只能用下班時間加減拜一下。

是說關於Vanilla JS 的互動部分，我覺得會需要突破一些思考框架問題，
現在的思路大概是：

1. HTML本身就是並不是單純的介面標記，DOM跟程式不是分開的，是緊密結合的。
2. 資料不一定要存在Javascript管理的記憶體裡面，你也可以把它存在網頁上，用Markup的方式。
3. 雖然很多人可能對2的做法有很大疑慮，怕被使用者亂改什麼的，但其實這個安全性從來沒有過。所以放心去用吧，伺服器端做好檢查就好。
4. 不要覺得自己在寫程式，想像是路邊發送的傳單，下面有虛線可以把折價券/問券剪下來寫一寫交回去的那種。
貼文太長了。點這裡查看全文。


YouTube embed. Click thumbnail to play.

730214ed No.356[回覆]

VS Code Agent Mode Just Changed Everything

Agent和MCP都有了
也順便用實作解釋了Agent和MCP在運作時的差別
現在CP值最高的付費coding AI是github copilot嗎? 想訂了

File: 1744516197098.jpg (506.38 KB, 2552x2060, [email protected])

a094a6e4 No.353[回覆]

https://x.com/infobeautiful/status/1787873798273802520

4位數字密碼分佈圖
對角線重複數字
19開頭西元生日年份
左下角MMDD生日
還有1234 4321這種連續數字

不過7410和2580就不太知道為什麼了

07f5243c No.354

File: 1744524780423.jpg (66.11 KB, 1000x1000, 1000x1000.jpg)

>>不過7410和2580就不太知道為什麼了

按鍵手機時代的數字鍵排法。


YouTube embed. Click thumbnail to play.

7f94e89a No.352[回覆]

Two decades of Git: A conversation with creator Linus Torvalds

YouTube embed. Click thumbnail to play.

7414abf2 No.348[回覆]

TaskbarX - Customize Your Windows Taskbar 2025

https://taskbarx.org

https://github.com/ChrisAnd1998/TaskbarX/tree/master?tab=readme-ov-file

雖然很討厭W11毫無靈魂跟理念的設計風格，
但不得不說W11相較W10效能跟穩定上是真的有不錯的提升。
純論性能我會想用W11工作，但W11有一個最受不了的地方就是工作列完全不給動。
某些早期版本可以用註冊表硬幹，但是這個Hack在21年的21H2版本也被徹底終結了。
https://pureinfotech.com/move-taskbar-top-side-windows-11/

最近幾年除非買二手機，不然要搞W10可以說是越來越難。
原本想來自己寫一個小程式工作列，但突然又想到這件事情一定有別人想過，
果然還是我太孤陋寡聞。
貼文太長了。點這裡查看全文。

cf3b5039 No.349

Win11的Taskbar真的是用過最難用的一版
95的都比較好用
UIUX都設計的超爛

61636ef5 No.350

File: 1744388031786.png (11.48 KB, 968x299, NooTi.png)

結果太high沒看仔細，這東西是W10時代的東西。W11只要比較新的版本都沒辦法運作。

不過沒關係，我還有ExplorerPatcher

61636ef5 No.351

File: 1744388160930.png (1.9 MB, 1536x1024, 螢幕擷取畫面 2025-04-12 001151.png)

ExplorerPatcher玩了一陣，雖然有些亂七八糟的東西不太好處理。
不過終於可以亂調工作業位置了。
附圖是快樂的成果。


File: 1739557312909.png (196 KB, 1562x1000, 截圖 2025-02-15 02.06.09.png)

b12968fe No.279[回覆]

我是上串開IDE的，想了很有要不要另外開一串。
想說主題不一樣還是開了。
這陣子對我來說的另一個好消息大大概就是有位網友接手了
Notepad++的C#外掛模板維護吧。
之前就一直想寫Notepad++外掛來輔助一些日常操作。

但之前的C#模板太過久遠，編譯出來的外掛換到比較乾淨的環境上就跑不動。
找了半天發現是一個dll依賴.Net Framework 3.5的東西…
想試著班但是沒C++技能搬不動…
直到這幾天無聊去看才發現有人接手。
萬歲。

至於說VSCode，雖然是主流，但除了最初見到VSCode的那個專案很不愉快以外，
VSCode也沒有強大到能夠壓制住那個專案的回憶讓我喜歡上他，
他太過鬆散、隨意、缺乏整合性。
貼文太長了。點這裡查看全文。
8 則貼文 與 1 則含圖回覆 已省略。點擊回覆以查看

b12968fe No.341

TOML的部分，最後投降了，
Tomlyn雖然有把TomlTable開出來給我用，但是相關API很不完整。
只是有把東西開出來的程度，GetXXX 直接拿Object要自己轉型整個超出我能力範圍還要加上我跟TOML不熟。
現在只能乖乖把要儲存的部分分開一個類別單獨處理，然後Serialize/Deserialize了。
當初就是想避免這種狀況才想要手動寫文件的。

現在想想NewtonSoftJSON那個從頭包到尾完整又可靠的API真的是奇蹟。

3605a1c3 No.342

>>341
nuget上面好像還有其他的library，可以試試看?

不過主要原因應該是toml本來就比較小眾吧
這種時候你就該自幹一個開源(ry

然後往前看了一下，你本來是用ini
那直接找ini的library會比較輕鬆吧
畢竟是微軟來的東西，應該比較有支援

b12968fe No.343

File: 1743862976456.jpg (137.38 KB, 849x1031, Screenshot 2025-04-05 2156….jpg)

今天用物件寫出寫入搞了快半天，Tomlyn跟Tomlet這兩家都撞了一些奇怪的Bug。
Tomlyn雖然可以順利寫檔案，但是讀進來的時候跟我說無法設定某某Property。
Tomlet則是結構上搞不出想要的結構，然後讀取的時候疑似踩到編碼問題(丟繁體中文進去)。
結論是：已經在這邊卡太久了，先躲回微軟邪惡領土用XML去了。

>>342
>>nuget上面好像還有其他的library，可以試試看?

https://www.nuget.org/packages?q=TOML&includeComputedFrameworks=true&prerel=true&sortby=created-desc
我看看。
nuget上面頭幾個結果看起來像是給新的Extension框架增加TOML支援，
後面有Config的應該都差不多是這樣。
不過個別Package可能可以拆出來用。

剩下大概就 r-toml
貼文太長了。點這裡查看全文。

9f41d703 No.345

>>343
有找到這個看起來像是官方的ini api
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.configuration.ini

XML可以接受的話，直接用json比較好改吧?

92b5570f No.346

>>345

主要是工作上已經很多JSON了，下班想要嘗試點不一樣的。
本來想說Configuration相關的東西是跟設定檔高度綁定的，
不過仔細想想專案檔好像跟設定檔沒有差太多…
再找時間試試看。


YouTube embed. Click thumbnail to play.

1f0b6ab3 No.339[回覆]

Interview with Vibe Coder in 2025

出張嘴讓AI寫程式然後把報錯貼給AI自動debug是真的滿爽的 快變廢人了

c46e2d14 No.340

https://www.ettoday.net/news/20130117/153867.htm

想到很多年前的這個案例。
要爽可以，但是要小心不要變廢人啊。


File: 1743257043856.png (188.01 KB, 1086x940, 截圖 2025-03-29 21.42.55.png)

46853fb0 No.328[回覆]

前陣子跟人吵 .Net Framework 4.5到底有多過時的議題。
說真的在很多領域還有一堆更過時的東西，區區一個 Framework 4.5算什麼啦。
更不用說即使你編譯目標是4.5，新型windows上也是用 4.8 / 4.8.1 的Runtime去跑。
還有就是 4.8 以後就接到新型.Net去了，那個改動幅度根本是製造就業機會啊。
真的活該寫.Net…(這好像是另一串)

總之，
為了反嗆，我去查了一下才發現，傳說中的上古語言COBOL居然到2023年還有新規格。

https://zh.wikipedia.org/zh-tw/COBOL

實際上還有一些以為已經死了的東西卻還是在活著，也有一些看起來還活著卻像是死了的東西。

路過一篇文章：

貼文太長了。點這裡查看全文。

f250ea07 No.329

只要有銀行的核心伺服器還在用 COBOL就不會真的死掉吧
PHP也是寧願他已經死了就不用再維護前人留下的大屎坑

46853fb0 No.330

>>329

重點是COBOL意外還有改版跟更新。
雖然很多銀行用的應該是那張表上的 COBOL-86前後規格。

PHP要死很難，包括現在的K島跟這個網頁都是PHP。
這東西應該是asp之後第一個大紅的動態網頁架構吧，
開源特性跟超高普及率讓他基本死不了，或者即使死了，
也會常常以各種方式回來…

f10a5653 No.334

Fortran
https://fortran-lang.org/
2023還出了新版

R在資料處理領域活的滿好的


YouTube embed. Click thumbnail to play.

eae1a2c5 No.331[回覆]

Terminal Tips in VS Code

eae1a2c5 No.332

File: 1743305044832.jpg (123.74 KB, 1397x591, 螢幕擷取畫面 2025-03-30 112315.jpg)

vscode terminal的自動完成輔助功能
terminal intergrated suggest


YouTube embed. Click thumbnail to play.

1cfe52d3 No.306[回覆]

Why You Shouldn't Nest Your Code
8 則貼文 與 2 則含圖回覆 已省略。點擊回覆以查看

bf672d5f No.319

>>318
不是餵AI給的回答

switch的快慢取決於語言和資料大小

dictionary[] 儲存計算值在記憶體中的各個位置。當dictionary[]找不存在的計算值時，會新增延遲。

當switch使用類似array()的連續記憶體區域時，switch可能會比dictionary[]使用的hash table更快。否則，switch速度較慢。

array()記錄大量資料時會變慢：array()將所有字串儲存在其整個範圍內的記憶體中，或在 C/C++ 等語言中手動分配內存，直到明確釋放記憶體。對於大型數組，這可能會佔用大量記憶體。

當涉及到讀取資料時：switch 讀取資料以線性時間O(n)，而array()讀取資料以更快的恆定時間O(1)。hash table對於小數據是 O(1)，對於不確定的大數據是 O(n)。if時間複雜度為O(1)。 nested if時間複雜度有不同意見。 從 O(1) 到 O(m*n)。最基本的nested for-loop的時間複雜度是O(n^2)。

c3096d4c No.321

是說樓上一直有人講Dictionary/HashMap，
不過以我自己的認知，if/else-if 結構最大的優勢不就是
「設計得當的時候可以避免不必要的判斷」？

變成 Dictionay / HashMap 的結構不就表示要把所有條件都檢查一遍？
這樣不是浪費一堆算力？ 也難怪 case 裡的東西都會被要求是常數。

然後
>>307

這個波動拳，其實只需要放開心胸去搞清楚if-elseif 的執行方式。
完全可以用if-elseif 拉平。
這類型好像曾經是專科跟半路出家的鑑別器，
基礎不好的就很容易寫出這種東西，
有人帶的可能是很多組if或者是一片平的if-elsif。

04d068e7 No.322

File: 1742317584966.png (49.41 KB, 438x478, Screenshot_2025-03-18_09-5….png)

>變成 Dictionay / HashMap 的結構不就表示要把所有條件都檢查一遍？

都檢查一遍 ===> if key in dict: ====> O(n)

if dict.get(key): =====> O(1)

dbecdd7c No.326

>>322

老兄你這個範例會把加減乘除都算一次耶。
今天你只是加減乘除，
如果換成更複雜的計算不就全部都要跑一次？

dbecdd7c No.327

不覺得Switch/Case會難維護。
現實來說就是會有一個input有N種狀態的狀況。
會有問題的其實是遇到可以拆出去變另一個方法卻還是硬寫在一起把層數拉高，
或者判斷先後順序明確，可以用if/elsif+return卻硬要弄成狀態機用
switch/case，基本上就是這篇開頭影片在講的nesting。
雖然對電腦來說做的事情差不多，
但不可否認把原始碼的層數控制住還是會對可讀性有幫助。


  [Go to top]   [Catalog]
刪除貼文 [ ]
上一頁 [1] [2] [3] [4] [5] [6]
[ 首頁 / 搜尋 / 管理Discord ] [ Komica首頁 ] [ 跨版面 ] [ 雜談 / 車 / 攝影 / 運動 ] [ 人工智慧 / 程設交流 ] [ 蔚藍檔案 / 英雄聯盟 / 米哈遊 / Minecraft / 魔物獵人 / 勝利女神：妮姬 / Pokémon / 刀劍亂舞 / Unlight ]