網頁教學

幾乎沒有哪個客製化 Web 應用開發專案是從一份規格書開始的。它通常始於一張試算表，某個人為了追蹤一件事而建立，後來加了第二欄，再後來多了一個工作表，最後加進一條只有一個人看得懂的公式。三年之後，那個檔案裡裝著排程、價格和一半的客戶資料，四個人同時在編輯它，而沒有人能有把握地說出哪一份副本才是最新的。 那才是真正的決策點，也是多數自建與採購之爭的文章沒有觸及的地方。你要選的並不是一張白紙和一件成品。你要選的是從一套還能運作但已經很脆弱的流程中脫身的三條路：買一個產品，在無程式碼平台上拼裝一個，或者依照自己的做事方式委外開發一套軟體。 該開發客製化 Web 應用，還是採購 SaaS？ 預設是採購，除非三個條件裡至少成立兩個：這項流程是...

漸進式網頁應用程式開發，是英國買方在專案開始的頭十分鐘裡排除掉、又在十八個月後重新發現的方案，那時第二套原生程式碼庫已經悄悄吃光了預算。它之所以被排除，是因為關於它的文章幾乎都落在兩個陣營裡：跳過 iOS 拒絕做的那一部分的鼓吹，或者承襲自 2019 年、當時平台確實做不到的懷疑。 兩者現在都錯了，而且錯在會改變成本計算的地方。自 iOS 16.4 起，Safari 已支援加入主畫面的網頁應用程式發送推播通知。Chrome 取消了安裝對 Service Worker 的要求。英國主管機關在 2025 年 10 月認定 Apple 與 Google 在行動瀏覽器與瀏覽器引擎上具有策略市場地位。同時 iOS 仍然拒絕背景執行，會依你無法...

組建軟體開發團隊的決定，通常不是以計畫的形式出現，而是以一行預算的形式出現。有人核准了兩名工程師的員額，董事會文件上寫著擁有程式碼比租用程式碼便宜，而在還沒有人寫下這支團隊究竟為何存在之前，找人就已經開始了。由此產生的招募錯誤，會有大約九個月的時間完全看不出來。 提出這個問題的人裡，大多數還不該找人，誠實的建議就從這裡開始。一支正職員工組成的團隊是固定成本，而與之對應的需求通常是波動的。它行得通的前提是工作持續不斷，客戶付錢買的就是軟體本身，並且公司裡有人說得出下週該做什麼。三者缺一，你就把本來可以按日購買的東西按年買了下來。 以下要談的是這筆帳和這個順序: 把國民保險、退休金、假期、設備與招募費用都算進去之後，一名工程師究竟要花多...

企業軟體開發服務這個說法，照大多數開發公司網站上的用法，指的就是同樣的工作貼上一個更大的數字。團隊一樣，流程一樣，提案裡多了一面客戶標誌牆，價格翻了三倍。買方心裡有數，所以採購部門早就學會略過這個詞，直接去讀合約附件。 底下確實有一個真實的區分，而且它跟公司規模無關。一家 40 人的保險公司可以跑一個貨真價實的企業級專案，一家 12,000 人的零售商也可能只是訂了一個網站。區分它們的是這套系統加在建置方身上的義務：它必須跟多少其他系統對話，允許停多久，誰能否決一次上線，哪個主管機關對它有興趣，以及供應商撒手不做時會發生什麼事。 以下用這些義務來定義這個類別，好讓買方分得出誰扛得住，誰只是替一個普通專案加了一張企業級的封面。 到底是...

搜尋倫敦客製化軟體開發，會跳出好幾百家公司，對外看起來一樣的工作，報價卻從每天 400 英鎊到 1,800 英鎊不等。幾乎沒有一家公開價格。這個價差是真實的，也解釋得通，但那些網站上沒有一處解釋它，而手上拿著三份提案的買方，分不出貴的那份究竟是比較好，還是只是比較貴。 底下要講的是這個價格如何被搭起來：倫敦日費率底下的薪酬成本與不動產成本、開發公司會提供的四種商業模式、混合費率掩蓋了什麼，以及一個特定形態的專案在把需求探索、測試、資料移轉和第一年支援都算進去之後要花多少錢。文章也會談到那些比費率更能決定結果的合約條款。 這裡的費率是我們根據倫敦實際報出、贏下與輸掉的案子得出的自有估算。凡是來自官方來源的數字，都註明出處與日期。 在倫...

你能找到的幾乎每一篇 Salesforce 與 HubSpot 的比較，都是由其中一方的合作夥伴寫的。這不是陰謀，而是經濟事實：能把這兩款產品了解到足以比較的人，都靠導入其中一款維生。結果就形成了一種文體，給一款產品最有力的辯護，給另一款一份客氣的缺點摘要。 我們同時導入並整合這兩款產品，也曾把客戶往兩個方向都搬過。以下是我們隔著桌子回答客戶提問時會給出的比較，價格是 2026 年 9 月從各廠商自己的定價頁讀來的，平台額度是從各廠商自己的文件裡讀出來的，而不是憑記憶寫的。 簡短的結論是：每篇比較都放在最前面的授權價格，是這個決定裡最小的一個數字。真正決定結果的兩個數字，是這套系統每個月需要多少管理投入，以及第三年你改變主意時要付出...

搜尋 wordpress vs wix，第一頁幾乎每一筆結果都在付佣金給某個人。Wix、Squarespace 以及大型代管式 WordPress 主機商全都在經營聯盟行銷計畫，比較型網站的存在就是為了收割這些佣金，推薦結論在任何研究開始之前就已經由分潤表決定了。這就是為什麼那些結論聽起來都是同一個調子，也是為什麼它們回答的是一個沒有哪家企業真正提出過的問題。 企業真正的問題不是哪個平台最好。這三個都足以支撐一個 15 頁的形象網站，其中兩個還會比一套疏於管理的 WordPress 做得更快、更可靠。真正的問題是這個網站三年後必須做到什麼，以及不論你選中哪一個，離開它要付出多少代價。 寫這篇文章的是一家靠把網站從這三個平台上搬走賺錢...

多數在找 Drupal 技術支援的人，手上已經有那個網站了。它可能是從一家早已轉身離開的接案公司接過來的，也可能是從一位離職的開發者那裡繼承下來的，而現在更新已經逾期，某個表單不再寄信，或者一份安全公告落了下來，卻沒有人說得清它是否適用於自己。他們要的不是一頁銷售文案，而是一份範圍文件：工作到底是什麼、一份公平的合約該怎麼寫，以及它應該值多少錢。 這篇文章就是那份文件。它列出一個 Drupal 網站每個月真正需要的工作、決定一份維護合約值不值錢的營運事實，以及英國實際的價格區間。請把廠商的提案攤在旁邊一起讀，因為真正有用的部分，是發現那份提案沒有回答哪些問題。 有兩件事讓 Drupal 不同於一般的網站維護。它的安全公告依照公開的時...

對大多數網路商店來說，Drupal Commerce 都是錯的答案。這並不是在批評這個專案，它十五年來的工程品質一向紮實。這只是在陳述大多數商店的樣貌：幾百個 SKU、一種貨幣、面向消費者的客戶，最後刷一次卡。對這種形態的生意而言，代管型平台在每一個重要的面向上都會勝出，爭論還沒開始就已經結束。 但確實有一小群商家，他們的帳算下來完全相反，而且這是一群利潤可觀的商家。無法用變體表格表達的可組態產品。帶有議定價目表的貿易帳戶。目錄本身就是編輯內容。由 ERP 掌握庫存與價格，網站只是一個展示面的公司。在這些生意裡，代管型平台並不便宜，它是一筆長期繳納的稅，以應用程式、變通做法以及「這裡不准動」的形式支付。 本文要說清楚那條界線究竟落在...

Drupal 12 預定在 2026年12月7日那一週推出，而 Drupal 10 會在 2026年12月9日走到生命週期終點。這兩個日期就印在 Drupal 核心發布時程的同一頁上，中間只隔兩行，可是絕大多數正在經營 Drupal 10 網站的人，兩個都沒注意到。新大版本的第一個 alpha 已經在 2026年9月2日打上標籤，所以這次發布的樣貌現在是有案可稽的事實，而不是臆測。 這場對撞就是整篇文章的重點。一個大版本問世，對網站擁有者來說通常並不急迫，因為你大可在舊的大版本上待個一兩年，等生態系跟上。這一次不一樣，舊的大版本會在新版本推出的同一週停止收到安全公告，於是一個技術事件變成一個帶著法遵鋒刃的期限。...