顯示具有 電腦資訊 標籤的文章。 顯示所有文章
顯示具有 電腦資訊 標籤的文章。 顯示所有文章

2026年9月11日 星期五

Spring Boot:建置與執行

 


在漫長的 Java 語言開發平台發展路途中,自從由官方主導的 Java EE 被開源社群擁護的 Spring 攻城掠地後,長期不動如山的 Servlet 網頁程式開發技術,也逐步被 Spring MVC 取代。然而,Spring 框架越來越龐大的類別庫相依性,卻成為 Java 工程師建置開發環境時的夢魘。Spring 開發團隊敏銳地發現,如此龐大的開發成本將會阻礙框架的普及,因此推出了 Spring Boot。其簡化的依賴性管理、簡化的部署以及自動組態三大特性,讓 Spring Boot 重新成為 Java 開發者喜愛的程式框架。

其實之前就已經看過兩本 Spring Boot 的專書,也已經將手上的專案全數改成 Spring Boot 框架。因此,閱讀這本《Spring Boot:建置與執行》的原意,只是單純想湊齊看完市面上這一主題的書。特別是由O'REILLY出版的電腦叢書,早期在 Java 領域裡幾乎等同於官方教材般的尊榮地位。雖然隨著網路興起,類似資訊隨手可得,讓系列叢書逐漸變得乏人問津,不過這兩年開始發現,碁峯和O'REILLY聯手出版的新書,有著充實的技術說明,輔以實用的程式範例,相當類似我最欣賞的Manning出版社In Action系列書籍。而在看完這本《Spring Boot:建置與執行》後,一方面吸收到之前兩本書中所沒有的內容,另一方面也重新溫習了已經學過的技術。

書中從最基礎的Spring Initializr專案建置工具講起,先用最單純的 Hello World 程度 REST API 程式,向讀者展示 Spring Boot 是如何簡化網頁程式開發的複雜度。接著再話說從頭,細數應用程式組態在 Spring Boot 框架下的規則,以及如何靈活運用。有如JMX 的致動器(Actuator)便是這本書獨有的章節;其他像是如何打包、部署成容器,也都是其他書裡沒提過的內容。和資料操作有關的 Spring Data 幾乎是必講的重頭戲,書中一次展示如何連接關聯式資料庫、MongoDB、Redis 三大儲存體,讓讀者不論挑選哪一種儲存技術,都可以找到參考範例。

全書我覺得最值回票價的部分,是學到了 Spring WebFlux 的反應式網頁程式(Reactive Programming)技術,以及之前一直沒有實作的 WebSocket 應用。也因此茅塞頓開地弄懂了 React、Reactive、WebSocket 三種常同時被提及,卻又截然不同、用來改善網路程式瓶頸的技術。甚至讓我破除了單一主機 TCP 連線只能到 65,535 條的迷思,可說是收穫滿滿,開卷有益莫過於此。


Throughout the long history of Java development platforms, Java EE was once the official choice for Java developers. However, after Spring, supported by the open-source community, gradually became more popular, the long-standing Servlet-based web development technology was also gradually replaced by Spring MVC. However, the growing number of library dependencies in the Spring Framework became a nightmare for Java engineers when setting up their development environments. The Spring development team quickly realized that such a high development cost could prevent the framework from becoming more popular. So, they introduced Spring Boot. With three major features — simplified dependency management, simplified deployment, and auto-configuration — Spring Boot once again became one of the most popular frameworks among Java developers.

Actually, I had already read two books about Spring Boot and had also migrated all of my current projects to the Spring Boot framework. Therefore, my original reason for reading *Spring Boot: Build and Run* was simply to complete my reading of the books available on this topic. In particular, computer books published by O'Reilly once had an almost official-textbook-like status in the Java field. However, as the Internet became more popular and similar information became easily available online, these book series gradually became less popular. Over the past two years, however, I have noticed that the new books jointly published by CITE Publishing and O'Reilly provide detailed technical explanations along with practical programming examples. They are quite similar to the *In Action* series published by Manning, which is one of my favorite book series. After finishing *Spring Boot: Build and Run*, I learned some new things that were not covered in the previous two books. At the same time, I also reviewed some technologies that I had already learned.

The book starts with the basic project creation tool, Spring Initializr. It first uses a very simple Hello World-level REST API example to show readers how Spring Boot can simplify the complexity of web application development. The book then goes back to the basics and explains the rules of application configuration in Spring Boot and how to use them flexibly. The Actuator likes JMX is one of the topics that I had not seen in the other books. Other topics, such as how to package an application and deploy it as a container, are also not covered in the other books I have read. Spring Data, which is related to data access, is naturally one of the major topics in the book. It demonstrates how to connect to three major types of data storage: relational databases, MongoDB, and Redis. No matter which storage technology readers choose, they can find useful examples in the book.

The part of the book that I found most valuable was learning about reactive web application development with Spring WebFlux and finally getting some hands-on experience with WebSocket, which I had never implemented before. Because of this, I finally understood the differences between React, Reactive, and WebSocket. These three terms are often mentioned together, but they are actually completely different technologies that can be used to address different kinds of problems in web applications. The book even helped me get rid of my old misunderstanding that a single host can only have 65,535 TCP connections. I learned a lot from this book. This is probably the best example of how reading a good technical book can be truly useful.


2026年8月24日 星期一

Python修仙之路:VS Code + GitHub Copilot──從AI輔助學習到專案開發,全方位提升你的「程式閱讀力」

 


自上次研究 Claude Code 後,開始接觸到 AI 代理人程式開發,想當然耳也會想評估一下另一個鼎鼎有名的 GitHub Copilot,試著找出兩者的差異,而這本由陳會安撰寫的《Python 修仙之路:VS Code + GitHub Copilot》就成了我開箱 GitHub Copilot 的入門書。談起陳會安這位作者,真的算是位奇人。我 20 多年前初出社會、謀職時買的第一本電腦書,是講 ASP 網頁程式設計,作者就是他!除了是長青的資訊技術作者外,看到他掛名的著作能從 C 語言跨到 AI 工具,真心覺得這就是十八般武藝都略懂略懂的人吧。

就我來看,這本書的定位不太討喜。對於真正的程式開發者來說,介紹的內容都是日常工作中必備的基礎知識。從程式語言的基礎、程式碼的重構與優化、程式除錯以及版本控制,到最後的容器化部署,這些作業即使不使用 GitHub Copilot,對於工程師來說也不費吹灰之力。反過來說,如果書籍的目標讀者是完全不懂程式的門外漢,那這些內容又顯得節奏過於快速,造成知其然而不知其所以然的隱憂。不過,或許這正是 AI 代理人開發時代的特色,讓每個人都能在不了解細節的情況下,做出可以動起來的軟體,一切都像魔法般神奇。

在完讀這本介紹 GitHub Copilot 的作品後,大略體驗了這個工具的基本功能和能耐。感覺它是從原本程式開發 AI 助理的定位逐步調整,慢慢朝向 Claude Code 的AI 代理人模式前進。換言之,它本身具有能加速程式人員撰寫程式碼的傳統功能,再疊加上現在最熱門的下指令讓 AI 寫程式的技術,變成魚與熊掌都要的 AI 產品。可惜的是,畢竟 AI 代理的思維,感覺是 GitHub Copilot 後來才添加進去的,所以在整體的使用細節和功能完整性上,是落後 Claude Code 的解決方案。如果用汽車來比喻,它就像是油電混合車,既不像傳統方式要求工程師純手動、一行行刻出程式碼,又不完全讓 AI 代理人從無到有產製出近乎成品的專案。對於 IT 部門管理者和第一線的開發者來說,拿捏在什麼情境下要使用自動完成、什麼時候又該尋求 AI 代理,以及在工程師與這類 AI 工具協同工作的情況下,未來程式碼的質、量管理要如何調整、考核,這些都是要額外討論、思考的議題。

After researching Claude Code, I started getting into AI agent-based software development. Naturally, I also wanted to take a look at another famous tool, GitHub Copilot, and see what the differences are between the two. This book, *Python Cultivation: VS Code + GitHub Copilot*, written by Chen Hui-An, became my beginner's guide to trying out GitHub Copilot. Speaking of Chen Hui-An, I really think he is quite an interesting author. More than 20 years ago, when I first entered the workforce and was looking for my first job, the first computer book I bought was about ASP web programming. And guess what? He was the author! Besides being a long-time writer of IT books, I was also surprised to see that his books cover such a wide range of topics, from C language to AI tools. Honestly, I feel that he is the kind of person who knows a little about almost everything.

In my opinion, the positioning of this book is not very appealing. For real software developers, most of the topics covered in the book are basic knowledge that we need in our daily work. From programming language basics, code refactoring and optimization, debugging, and version control, all the way to container deployment, none of these tasks are very difficult for engineers, even without GitHub Copilot. On the other hand, if the target readers are complete beginners who know nothing about programming, the book moves too quickly. There is a risk that readers may learn how to do things without really understanding why they work. However, perhaps this is exactly what makes the age of AI agent-based development special. It allows almost anyone to build software that actually works without understanding all the details. Everything feels almost like magic.

After finishing this book about GitHub Copilot, I got a basic idea of what this tool can do and experienced some of its main features. I feel that it is gradually moving away from its original role as an "AI assistant for software development" and moving toward the AI agent approach of Claude Code. In other words, it still has its traditional features for helping programmers write code faster, while also adding the increasingly popular approach of simply giving AI instructions and letting it write the code. It is trying to have the best of both worlds. The problem is that, since the AI agent approach seems to have been added to GitHub Copilot later, it still falls behind Claude Code in terms of overall usability and completeness. If I use a car as an example, GitHub Copilot is like a hybrid car. It is neither like the traditional approach, where engineers manually write every line of code, nor does it completely let an AI agent build an almost finished project from scratch. For IT managers and frontline developers, deciding when to use traditional code completion and when to turn to an AI agent is now another issue to think about. At the same time, when engineers work together with these AI tools, we also need to rethink how the quality and quantity of future code should be managed and evaluated. These are all issues that require further discussion and thought.


2026年7月28日 星期二

Claude Code Vibe Coding 開發手冊 第 2 版

 


即使不像對岸因高失業率引發的各行各業「內捲」那般慘烈,在台灣,近年來資訊科技相關工作的日子,也越來越不輕鬆自在了。除了像 Claude Code 這類強大的 Vibe Coding 工具緊追在後之外,IT 技術本身的突破與迭代速度也快得令人措手不及。以前可能學個 COBOL,就能安穩地寫二十年的銀行系統;學個 SQL,也能在中小企業的 MIS 部門一路做到退休,這種好日子已經一去不復返。現在資訊技術的保鮮期,多則不到兩年;像 AI 領域更誇張,新東西可能不到半年就過時,又得重新學起。

以這本《Claude Code Vibe Coding 開發手冊 第 2 版》為例,上市日期是 2026/06,離今天大概也才一個月。書中提到建立 subagent 的 /agents 指令,就已經被原廠停用、廢棄了。雖然就學習、使用的角度來說,這並不會造成太大的困擾,依舊能改用口語式指令操作,但對出版社、作者等教學方而言,撰寫、出版 AI 技術書籍的性價比肯定不高。畢竟,相較於討論底層核心觀念、歷久彌新的電腦書,這類 AI 熱門主題書如果不能在出版當年賣掉,大概也只能被秤重回收了。所以看電腦書,尤其是主題偏向 AI 實作時,近來得出的心得是:有需要再買,買了就馬上看,千萬不要積書!

由於我才剛看過這本書的第一版,因此能很明確地比對出新增加的章節內容。整體而言,基本概念與操作方式變化不大,實作練習則略有增加,翻閱時本質上比較像是在看別人做習題。因此,本書真正有價值的地方,在於 Claude Code 新功能的介紹,像是將特定執行流程 SOP 化的 Skills,以及跨平台的遠端操控功能。另外,內建 MCP 的 Claude in Chrome,也讓我眼睛一亮,更確切地體認到,在 AI 工具的協助下,未來的網路環境中,爬蟲機器人將會是再也無法阻擋的必然存在。還是那句老話,程式開發人員已經不能不懂 Vibe Coding。來一本吧!

Even though Taiwan is not facing the same serious "involution" as China, where high unemployment has made competition much tougher, working in the IT industry here has also become more stressful in recent years. Powerful Vibe Coding tools like Claude Code are moving forward very quickly. At the same time, new IT technologies are changing faster than ever. In the past, you could learn COBOL and spend twenty years writing banking systems. If you learned SQL, you could also work in the MIS department of a small or medium-sized company until retirement. Those days are gone. Today, many IT skills stay useful for less than two years. The AI field changes even faster. A new technology may become old in less than six months, and then you have to learn something new again.

Take this book, *Claude Code Vibe Coding Developer's Guide, 2nd Edition*, as an example. It was published in June 2026, only about one month ago. However, one command for creating a subagent has already been removed by the official developer. Luckily, this does not cause much trouble for readers. We can still do the same thing by using natural language commands instead. Still, for publishers and authors, writing AI books is probably not a very good business. Unlike classic computer books that teach basic ideas and stay useful for many years, AI books can become outdated very quickly. If they do not sell soon after publication, they may end up being recycled. Because of this, I have learned one important lesson about computer books, especially AI books: buy them only when you really need them, and read them right away. Don't let them sit on your bookshelf for too long.

I finished the first edition not long ago, so it was easy for me to see what had changed in this new edition. Overall, the basic ideas and operations are almost the same. There are a few more hands-on exercises, but reading them feels a little like watching someone else solve homework problems. The most valuable part of this book is its introduction to Claude Code's new features. For example, it explains Skills, which can turn common workflows into standard operating procedures (SOPs). It also introduces remote control across different platforms. Another feature that impressed me was Claude in Chrome, which comes with a built-in MCP. It helped me realize that, with the help of AI, web-crawling bots will become an unavoidable part of the future Internet. As I always say, software developers can no longer ignore Vibe Coding. Go get a copy of this book!


2026年7月16日 星期四

LangChain 奇幻旅程:OpenAI x Gemini x 多模態應用開發指南

 


AI 浪潮席捲而來的當下,軟體工程師若想不被大浪滅頂,勢必得將它視為助力而非阻力。唯有動心起念、善加運用,才能立於不敗之地。而對第一線的程式開發者來說,面對 AI 可以學習的方向,大致可分成兩個主題:一是人工智慧的 Vibe Coding 開發工具,增益自身的開發能量;二是探索與實作 AI 應用程式,將 LLM(大語言模型)的大腦融入不同的應用情境,開發出新世代的智慧程式。

在軟體開發的過程中,程式框架(Framework)具有將重複性需求規格化、模組化的優點,框架優先的觀念早已在 Web 應用開發中根深蒂固。在 LLM 應用的領域裡,LangChain 則是最具知名度的程式框架,其核心理念是透過它所提供的抽象層,達成不受制於單一 LLM 平台或業者的設計。這本《LangChain 奇幻旅程》不僅讓讀者學到 LangChain 框架的基礎,更進一步介紹 AI 應用開發會觸及的相關技術,像是本地端模型的 Hugging Face、Ollama、RAG 的觀念與實作、LINE Bot 對話機器人,以及極具價值的 Qdrant 向量資料庫基礎運用。

書中不偏袒地將 OpenAI 與 Gemini 這兩個 LLM 領頭羊的實作一併收錄,不論讀者原本採用的是哪一家的方案,都可以直接從書中學到具備即戰力的開發技能。可惜的是,AI 技術一日千里,即便這本書出版至今才約一年半(2024 年 10 月出版),LangChain 的版本已經歷多次更新,書中的程式碼也大多已經過時,得自行花時間查找新版的寫法。幸好身處 AI 時代,在 ChatGPT 這類工具的協助下,相信都能迎刃而解。

不過,對於 AI 應用的開發是否非得採用 LangChain 這樣的框架,目前我還是有點遲疑。以我比較熟悉的 GCP Vertex AI 為例,有一些平台專屬的功能,像是格式化輸出(Structured Output)、Grounding 等,都不包含在 LangChain 基本類別的設定值裡。換言之,如果想使用這些強大的 LLM 功能,就得客製化框架的程式碼;然而,一旦這麼做,就很難再切換到其他 LLM 平台,如此一來,採用框架所追求的平台無關性(Platform Agnostic)也就不復存在了。

With the AI wave sweeping across the software industry, developers who don't want to be left behind need to see AI as an opportunity rather than an obstacle. The key is to embrace it and learn how to use it effectively. For software developers, there are two main directions for learning AI. The first is using AI-powered development tools, such as Vibe Coding, to boost productivity. The second is exploring and building AI applications by integrating the "brain" of LLMs (Large Language Models) into different use cases to create the next generation of intelligent software.

In software development, frameworks help standardize and modularize common requirements, making development more efficient. As a result, the "framework-first" mindset has become deeply rooted in modern web development. In the world of LLM applications, LangChain is probably the best-known framework. Its core idea is to provide an abstraction layer so developers are not tied to a single LLM platform or vendor. This book, LangChain 奇幻旅程 (The Fantastic Journey of LangChain), not only teaches the fundamentals of the LangChain framework, but also introduces many important technologies used in AI application development. These include local models with Hugging Face and Ollama, the concepts and implementation of RAG, LINE Bot development, and the basics of using the Qdrant vector database.

The book presents examples for both OpenAI and Gemini without favoring either one. No matter which LLM platform you are currently using, you can learn practical development skills that are immediately useful. The downside is that AI technology evolves incredibly fast. Although the book was published only about a year and a half ago (October 2024), LangChain has already gone through multiple major updates. Much of the sample code is now outdated, so readers will need to spend some time figuring out the new APIs and coding style. Fortunately, with AI assistants like ChatGPT, updating the code is much easier than it used to be.

That said, I'm still not completely convinced that AI applications must be built on a framework like LangChain. Take GCP Vertex AI as an example. It provides several platform-specific features, such as Structured Output and Grounding, that are not covered by LangChain's standard abstractions. In other words, if you want to take advantage of these advanced LLM features, you'll need to customize the framework. Once you do that, however, switching to another LLM platform becomes much more difficult. As a result, the platform-agnostic design that frameworks like LangChain aim to provide starts to lose its value.


2026年7月12日 星期日

Java程式設計師應該知道的97件事:來自專家的集體智慧

 

ISBN:9789865027148

我自從約15年前因為專案需要實作訊息佇列,開始著手研究 Apache ActiveMQ 這個開源產品後,程式開發的重心也從微軟的 .NET 平台轉向 Java。而後又更進一步採用 Apache Camel 這個開源框架打造訊息交換平台,接著步入 Hadoop 大數據開發領域等因緣際會下,就此熟悉並喜愛 Java/Apache 相輔相成的軟體生態系。想當然耳,看到這本《Java程式設計師應該知道的97件事》的書名,毫無遲疑地就會買來翻閱,想瞧瞧所謂專家們的智慧。

這本書的編輯形式相當獨特,它匯集了97位頂級的 Java 開發人員,請他們各自以一篇文章分享自身認為 Java 程式設計人員最該關注的事情。由於書後的附錄收錄了這群人的經歷簡介,可以發現他們每一位都足以被稱為大神的頂尖工程師,不論是出身正統科班的 IT 博士、開源專案的貢獻者、資訊書籍的作者,還是服務於大型企業的顧問、講師。來自四面八方的宗師級人物,依據他們各自深切關心的議題,文章探討的內容也因此五花八門,從 Java 語法細節、JVM 效能工具、非 Java 的 JVM 語言,到軟體測試、專案管理、參與社群等等。內容可說是超乎想像地豐富,但又名副其實地淺嘗即止。

所謂人多口雜,此書的缺點也輕而易舉地浮現,連書籍編輯都直接在序言中提出,97位專家的建言肯定會有相互衝突的部分,而且很多文章的重點可能放在非常枝微末節的語法問題,因此會產生一種奇妙的認知悖論:如果你讀了能產生共鳴,那表示你早就懂了;如果你的程度還不夠,看了也形同嚼蠟。整體來說,閱讀這本書的過程,既沒有學習到具體技能的成就感,也沒有獲得實用新知的充實感。對現階段的我而言,讀起來如同雞肋,只是多了一本曾經讀過的電腦書的回憶。

About fifteen years ago, I started working with Apache ActiveMQ, an open-source message broker, because I needed to implement a messaging queue for a project. Since then, my main development focus has gradually shifted from Microsoft's .NET platform to Java. Later, I adopted Apache Camel to build a message integration platform. Combined with my subsequent experience in Hadoop and big data development, I gradually became familiar with—and grew to appreciate—the Java/Apache ecosystem and the way its open-source projects complement one another. So when I came across the title *97 Things Every Java Programmer Should Know*, I didn't hesitate to pick it up. I was curious to see what insights these experts had to offer.

The format of this book is quite unique. It brings together 97 experienced Java developers, each contributing a short article about what they believe every Java programmer should know. The appendix includes a brief biography of each contributor, and it's clear that every one of them is a highly respected expert in the field. They include PhDs in computer science, contributors to open-source projects, authors of technical books, consultants, and trainers working for major companies. Because the contributors come from such diverse backgrounds, the topics covered are equally diverse. They range from Java language details, JVM performance tools, and JVM languages other than Java, to software testing, project management, and participating in open-source communities. The breadth of the content is impressive, but each topic is explored only briefly.

As the saying goes, "Too many cooks spoil the broth." The downside of this format becomes apparent as well. Even the editors mention in the preface that the advice from 97 experts is bound to contain conflicting opinions. In addition, many articles focus on extremely subtle language details. This creates an interesting paradox: if an article resonates with you, you probably already know the topic well. If you don't have enough background knowledge, however, the article may be difficult to appreciate or learn from. Overall, reading this book didn't give me the satisfaction of learning practical new skills, nor did it leave me feeling that I had gained many useful insights. At this stage of my career, the book felt somewhat underwhelming—neither bad nor particularly rewarding. In the end, it simply became another technical book that I can say I've read.


2026年7月6日 星期一

Claude Code Vibe Coding 開發手冊

 

ISBN:9789863128533

對於從事軟體開發工作的從業人員來說,看到新聞媒體不間斷地報導 AI(人工智慧)如何在資訊領域中高速成長、進化,間接讓矽谷網路、資通訊巨頭們有底氣大幅裁員、縮編,除了心裡不是滋味外,也總是抱持著懷疑:AI 真的能整合各種繁雜、混亂的系統知識,從無到有地生成零失誤的程式碼嗎?畢竟,以我使用 ChatGPT 的經驗,它在回答程式問題時,也時常答非所問,或充滿 AI 幻覺。這一切的疑惑,在看完這本《Claude Code Vibe Coding 開發手冊》後,就豁然開朗了。

Claude Code 是一個針對程式開發情境打造的 AI 大語言模型,而它的表現也讓我大為驚艷,更讓我直接體驗了什麼是 Vibe Coding(隨想編程)。藉由書中 Step by step 的引導,不論是哪個程度的程式開發者,都可以輕而易舉地踏入 LLM 協助開發的旅程。幾乎可以肯定,在 AI 模型進展到這個水準的情況下,未來軟體業的組織規劃、職務權責和工作形態,都將發生巨大的改變。

也因此,不論是上至 CTO(技術長)、IT 單位負責人,還是第一線實作的 PM(專案經理)、SA/SD(系統分析/系統設計)和 PG(工程師),都值得花點時間,親自淺嘗即止地使用 Vibe Coding 工具,絕對會讓自己開闊視野,並從另一個角度思考軟體產業未來的走向。Claude Code 這樣的 AI 開發工具,就像是運動場上的類固醇,能快速且無差別地強化使用者的程式開發能力。但「能力越強,責任越大」,沒有恰當的規範與管理,AI 工具所能造成的破壞也會等比例放大。工程師的誠信與敬業精神,在未來的軟體開發產業中,將會是無可取代的必要條件。畢竟,誰也不想把大規模殺傷性武器的按鈕,交到自己不信任的人手上吧?AI 程式開發工具,就有這樣的威力。

For people who work in software development, it is hard to ignore the news about how AI (Artificial Intelligence) is growing and improving at an amazing speed. Many reports also say that this gives big technology companies in Silicon Valley more confidence to cut jobs and reduce their workforce. Besides feeling uneasy about these changes, I always had one question in mind: Can AI really bring together all kinds of complex and messy system knowledge and create perfect code from nothing? From my own experience with ChatGPT, it often gives answers that miss the point or are affected by AI hallucinations when I ask programming questions. After reading Claude Code Vibe Coding Development Guide, however, all of my doubts disappeared.

Claude Code is a large language model designed especially for software development. Its performance truly surprised me and gave me a firsthand experience of what Vibe Coding is. With the book's step-by-step guidance, programmers of any skill level can easily begin their journey of developing software with the help of LLMs (Large Language Models). It is almost certain that, as AI models continue to improve, the software industry will go through major changes in its organization, job responsibilities, and ways of working.

For this reason, everyone—from CTOs and IT managers to PMs (Project Managers), SAs/SDs (System Analysts/System Designers), and programmers on the front line—should spend some time trying Vibe Coding tools for themselves. Even a short hands-on experience can broaden your perspective and help you think about the future of the software industry from a different point of view. AI development tools like Claude Code are much like steroids in sports. They can quickly and dramatically improve a programmer's development ability. But as the saying goes, "With greater power comes greater responsibility." Without proper rules and management, the damage caused by AI tools can also grow just as quickly. In the future, honesty and professionalism will become more important than ever for software engineers. After all, no one wants to put the button for a weapon of mass destruction into the hands of someone they cannot trust. AI programming tools have that kind of power.


2026年1月28日 星期三

第一次學Excel VBA就上手:從菜鳥成長為高手的技巧與鐵則

 

自從微軟成為 OpenAI 的大股東後,這家在 PC 時代不可一世的科技巨頭,憑藉精準的決策眼光,成功將自己推向了 AI 時代的核心角色。而這一切的底氣,或者更直白的說法,「鈔能力」,不可諱言地來自於替微軟奠定基礎的辦公室應用程式 Office 系列,特別是試算表 Excel,更是全球財務、數據處理、行政作業等領域中,無數專業人士愛不釋手的工具軟體。然而,要釋放 Excel 的真正潛力,使用者不得不走上學習 VBA 的道路,這樣才能實現更多自動化功能,減輕日常事務的負擔。

本書《第一次學 Excel VBA 就上手》是一本適合初學者的 VBA 入門書,與市面上其他書籍不同,本書並非條列式列出各種函數名稱和執行範例的字典型參考書。它從最基本的變數宣告、函數定義等基礎知識開始,幫助完全沒有程式經驗的讀者,通過一步步的實作,學會撰寫能在工作中實際運用的 Excel 程式碼。例如,與文書處理軟體 Word 的整合應用,能夠自動生成文件;與郵件收發軟體 Outlook 合作,實現大量寄送郵件並統計郵件收發數據;更進一步,還能與瀏覽器軟體 IE 整合,編寫簡易的網頁爬蟲或自動瀏覽任務。

書中還濃縮了前人的經驗,分享如何更有效地編寫 Excel VBA,例如用二維陣列代替雙迴圈寫入、利用工作表函數來實現程式邏輯等技巧。此外,還簡單介紹了 VB 開發者熟悉的使用者表單,並教導如何製作進度表來執行長時間的程式。對軟體工程師來說,書中介紹的功能都可以用其他程式語言來實現,但對非 IT 領域的讀者來說,與其花費大量時間學習程式語言,學習 Excel VBA 就能取得相當不錯的成效,從性價比來看,這是一次非常划算的投資。


2025年10月10日 星期五

AI應用程式開發 第二版|活用ChatGPT與LLM技術開發實作

 

時至今日,沒人會否認人工智慧(簡稱 AI)是一門顯學,更有不少專家學者宣稱,程式設計是 AI 可以取而代之的職務。先不論未來的事,在這個當下,對從事軟體開發的工程師來說,AI 至少在兩個層面造成業務上的改變,或用更正面的態度來說,是改善。

首先,以大語言模型(LLM)為核心製作出來的程式開發工具,無論是在 POC 開發、程式碼除錯、撰寫測試程式碼等各個開發環節,都能利用 AI 來加速作業。另一個層面,則是運用 AI 在自然語言處理上的超能力,打造出以往令開發人員卻步的各種人性化應用。而後者,就是這本《AI 應用程式開發》關注的重點。

它採用目前 AI 產業領頭羊 OpenAI 的解決方案,向讀者介紹如何整合 LLM 到自行開發的應用軟體中。首先免不了要進行一些技術觀念的鋪陳,介紹大語言模型的演進以及其背後的原理。雖然 LLM 表現得很像有智慧,但它終究只是運用統計數據來預測下一個字元的文字產生器,因此在現階段,仍不可避免地有兩個問題無法克服:一是垃圾進、垃圾出:餵給 LLM 的資料如果本身包含錯誤資訊,那模型本身也只會提供錯誤結果。另一個是幻覺問題:LLM 只是依據機率最高的規則來不斷產生文字內容,無法保證內容的正確性。

接著進入實戰部分,書中很快帶過 OpenAI API 的使用方法。受惠於 ChatGPT 將一切複雜性包裝在 Web API 後,讀者會發現只要按部就班地照著書中內容練習一遍,就馬上學會如何利用程式碼呼叫 ChatGPT 家族的 LLM 模型,包含聊天補全模型、視覺辨識、內嵌模型、文字轉語音、語音轉文字和圖片生成等,一瞬間能將世界最強大的 AI 整合到自己的專案裡。

書中也點出 LLM 能具體增強專案的對話能力、語言處理能力、人機互動能力,並以範例展現各種可能發展的 AI 應用,包括新聞撰寫、看影片寫結論、特定領域的專家問答和語音個人助理等等。書中也貼心地提醒,這些功能看似強大又美好,但呼叫 OpenAI API 是以 token 計價,開發者必須有控管成本的警覺性。

接下來是更有技術含量的章節,介紹用於增進 LLM 模型效果的各種技巧。從最簡單的提示工程開始,只要透過角色、前後文和任務的三段式文字,就能設計出有效的提示語;要求 LLM 進行一步步去思考,是另一種減少 AI 給出錯誤答案的小技巧。少量樣本學習以及根據使用者回饋來改進則需要花費更多心力在提示語撰寫。對於後者,書中更是提供用 AI 來優化提示語的範例程式。

再來是需要大量成本的微調模型。在 OpenAI 的工具中,微調 LLM 相當容易,但前提是使用者必須擁有能用來訓練模型的大量資料,以及充足的預算來進行這項作業。另外要注意,微調後的模型也只能在 OpenAI 平台中使用,無法帶走。最後則是現在的當紅炸子雞——RAG(檢索增強生成)以及連帶的內嵌模型。其實 RAG 是為了彌補 LLM 有著輸入 token 限制的問題,但因為實作簡單、效果顯著,所以目前已經變成 AI 應用的標準配備。

最後的章節則介紹 AI 應用程式在開發時的延伸議題,像是程式框架 LangChain 和 LlamaIndex。這部分也讓我看到 AI Agent(代理)在整合不同工具後,能展現出多強大的功能,像極了電影《鋼鐵人》裡的 AI 管家賈維斯。而透過OpenAI 規格的實作,讀者也可以自行開發提供給 LLM 呼叫的外掛工具,讓它更無所不能。可惜的是,AI 程式框架進展一日千里,書中的程式碼已經過舊,無法正常運作;不過也不用擔心,ChatGPT 神通廣大,可以輕鬆改寫出新版的程式碼。

在大數據時代,工程師已學會用數據寫出程式;相信在 AI 時代,工程師也會開始用 LLM 寫出程式。這本《AI 應用程式開發》,就是最棒的起點。


2025年9月4日 星期四

Next.js實戰

 

自從讀過《React 思維進化:一次打破常見的觀念誤解,躍升專業前端開發者》之後,我對 React 這個前端 JavaScript 工具庫已有初淺的了解。但在實際的前端開發領域中,由於 React 完全在客戶端執行的特性,雖然能獲得效能與吞吐量的優勢,相對地也犧牲了網站的 SEO 以及安全性。為了彌補這些不足,前端開發團隊通常會採用另一套建立在 React 之上的框架,而《Next.js 實戰》一書,正是為了引導讀者學習如何應用 Next.js 框架的入門書籍。

本書從各個面向介紹在使用 Next.js 開發前端網站時可能遇到的技術議題。在第一部分的基礎知識中,重點首先在於說明各種不同的元件渲染策略:CSR(Client-Side Rendering/客戶端渲染)、SSR(Server-Side Rendering/伺服器端渲染)與 SSG(Static Site Generation/靜態網站生成)。對傳統的網頁程式開發者來說,把 SSG 理解為生成靜態網頁內容,CSR 則是純 JavaScript 驅動的網頁應用,這兩者都算是比較容易理解的。但比較令人困惑的,大多是 SSR 與 ASP、PHP 等傳統網頁程式的差異,以及 Next.js 的 SSR 為什麼會被歸類為前端技術。簡單來說,是因為 Next.js 程式是以 JavaScript 編寫,而且多數邏輯與網頁畫面有關,處理的是版面套用與互動邏輯。深入來看,SSR 的回傳結果最終仍是以 HTML + JS 的形式送到瀏覽器,並由前端引擎執行程式碼,因此在運作機制上與傳統網頁程式確實不同。

接著,書中介紹另一個重要概念網頁路由。畢竟網頁應用最核心的功能之一就是頁面之間的連結與切換,所以學習框架的路由機制是必要的。這裡也同時介紹了 Next.js 提供的超連結元件與圖片元件,以及對 SEO 極為重要的 HTML Metadata 元件。透過修改 _app.js 和 _document.js 這兩個核心檔案,開發者可以達到一次撰寫、全站套用的效果,這樣的設計大幅提升開發效率。第二部分則著重於更具體的開發實作細節,例如:如何規劃專案目錄結構、如何在伺服器端與客戶端呼叫外部 API,並且帶出 GraphQL API —— 這是一種類似 SQL 的資料查詢語言。不過說實話,對於習慣使用關聯式資料庫或 NoSQL 的老開發者來說,GraphQL API 的吸引力可能並不明顯。

對於不使用資料庫的前端應用程式來說,儲存使用者狀態是一項挑戰。React 提供了 useState 與 useReducer 這兩個 Hook 來處理頁面層級的狀態管理;若要在不同頁面間共用資料,則可利用 Context API。至於 Redux,則是一個常被拿來取代 Context API 的全域狀態管理工具,在 React 生態系中廣受歡迎。由於前端開發無可避免地需要處理畫面套版,因此如何整合 CSS 也是 Next.js 中的重要議題。書中介紹了 Styled JSX、CSS Modules,以及更進階的 SASS 工具庫。此外,還包括如何整合 UI 框架以加快界面開發流程、如何將單執行緒的 Next.js 掛載到如 Express.js 等伺服器程式上。關於單元測試與整合測試 —— 這些在軟體專案中常被忽略的階段,書中也有專章說明其重要性與實作方式。

第三部分聚焦在商用網站不可或缺的功能:使用者身份登入與授權管理。書中詳細介紹了 JWT(JSON Web Token)這種廣為業界採用的資料安全機制。透過這套身份驗證實作,讀者也能重新溫習前面章節學到的核心知識。最後一章則以建構一個電子商務網站作為實例,完整示範如何使用 Next.js 打造具備商業應用價值的前端網站。在台灣,探討 Next.js 技術的書籍並不多,而《Next.js 實戰》正是一本能讓讀者在不踩雷的情況下學習核心觀念的實用電腦書,特別適合希望在短時間內快速了解 Next.js 基本用法的開發者。


2025年7月26日 星期六

文科生也能輕鬆實現!自建自用大語言模型(LLM):無痛操作Ollama本機端模型管理器

 

自從 OpenAI 的 ChatGPT 走入大眾視野、給知識工作者帶來意想不到的巨大震撼後,人工智慧(或簡稱 AI)就再也沒從媒體的熱門關鍵字排行榜中下滑。的確,先前深度學習也曾帶來一波 AI 熱潮,但那時頂多是在圖片、影像辨識上達成弱人工智慧,加速影像監控和自駕車等技術的發展。相較之下,LLM 可是開創了一個名為生成式 AI 的新資訊運用領域,並且在各種文字、圖像任務上,達成不遜於真人處理的成果。也難怪三不五時總會出現一些憂心之士,誤會並宣稱 LLM 已經產生自我意識,足以對人類造成威脅。

身處在這個 AI 浪潮中,從事知識工作的白領也不得不有危機意識,得加緊腳步接觸、瞭解 AI,進而能和 AI 協同作業,確保自己在職場中的競爭力。除了直接使用各大 LLM 平台的網站服務以外,自己從零開始裝設私有的 LLM 也是一種可行的做法,而這本《文科生也能輕鬆實現!自建自用大語言模型(LLM)》便是能讓你快速達成此目標的寶典。在開源程式碼和 LLM 開源模型的幫助下,只要手上有一台裝有 GPU 顯示卡的電腦,隨著本書的引領,你就會輕易地擁有一套屬於自己的 LLM 平台,不用付費就能隨意使用。當然,這個自產自銷的大語言模型肯定無法和市面上的商用方案比肩,但在處理一些小問題上,也足以分勞解憂。

市面上可以用來建置本機 LLM 的軟體方法很多,這也是讓許多想自行嘗試的人打退堂鼓的原因之一。本書聚焦在 Ollama 加上 Page Assist 這個簡易又可靠的配套方案,看到第二章就能讓讀者感受到打造本機 LLM 的感動與驚喜。雖然美中不足的是,書中並沒有介紹如何安裝可提供 REST API 的本機 LLM 環境,但已經能替讀者省下相當多試誤與爬文的心力,讓你我直接邁向構思應用的實作階段。如果剛好你是被主管或老闆指派來研究 LLM 技術的 IT 工作者,那《文科生也能輕鬆實現!自建自用大語言模型(LLM)》更是你千萬別錯過的好書,絕對能幫你增進對 LLM 的實作經驗與技術體悟。

2025年6月22日 星期日

Metadata後設資料:精準搜尋、一找就中,數據就是資產!教你活用「描述資料的資料」,加強資訊的連結和透通

 

這本書是線上開放式課程的教材重編而成,難免散發出濃濃的學術味,耐著性子看完,像極了去國外上一堂資訊科學的選修課程,還不用考期中、期末考。不過對在資訊圈打滾多年充滿實作精神的IT人而言,對書中終章講解後設資料如何應用較容易提起興緻,因此讀來會像倒吃甘蔗。語意網的願景是資料網,想藉由網際網路的通用普遍性,標註、聯結物理世界中的五花八門的所有物件,進而讓萬事萬物皆可被查詢和分析。妙的是,作者提及的後設資料的未來,解決IT系統整合的全代理程式或稱通用型代理程式,目前卻是由大紅大紫的AI大張旗鼓,試圖達成這個終極理想。在生成式AI對非結構化文字的超能力作用下,許多嘗試用結構化文字來優化資訊系統的自然語言處理技術都算是被打入冷宮,呈現出一種「倚天一出,誰與爭鋒」的態勢。然而語意網或是大數據運用中的標籤子系統,在系統穩定、效能和維運成本各方面還是有勝過生成式AI的優勢,在資訊處理系統的技術選擇上,「殺雞不用牛刀」也是種智慧。

實踐後設資料的資訊技術主要有結構化資料,或說更具體的是關聯式資料庫。另一個被提到的是可擴充標記語言(XML)或是更常見的超文件標記語言(HTML)。在概念上的指導技術則是一個通用的資源描述架構,名為都柏林核心後設資料組織抽象模型(DCMI抽象模型),這也是建立都柏林核心後設資料網要背後的理論架構。不過我相信記不起來沒關係,這名詞對大多數人來說看過就會忘記吧。

使用性後設資料、管理性後設資料和描敘性後設資料,已各自在不同資訊應用中扮演重要的角色。使用性後設資料的應用相當具爭議性,如維基解密所透露,任何組織都可以藉由分析電信系統裡的使用性後設資料,如號碼、時長和地點等資料,在不違法側錄對話內容的前提下,進行侵略性的監視和調查。使用性後設資料在大數據技術中被稱為資料廢氣,名稱看似有貶低之意,但如果做的對、做的好,那可是在浪裡淘金的生意。管理性後設資料旨在描述、定義資源要如何被妥善管理,可進一步細分成技術性後設資料,它最常見的應用是在數位影像領域中替軟硬體整合搭起橋樑,定義緒如檔案格式、解析度和曝光等資料。另外還有出處後設資料、保存性後設資料和權利後設資料,三者則是用在藝術品典藏和學術期刊引用這些特定用途的資訊系統中。描敘性後設資料則是大眾提及後設資料一詞的第一印象,畢竟後設資料的遞迴定義便是「用來描敘資料的資料」。而搜尋引擎最佳化(SEO)和大數據應用裡的標籤系統都是源自這種類型的後設資料。

越前面的節章就越偏向資訊處理的基礎概念。內容包括資源的唯一識別碼或是其具體實踐的統一資源定位符(URL)。不可免得還有更富有理論性質的東西,像是哲學的本體論、控制詞彙或稱為索引典和名稱權威檔等等。理論的終點是講到後設資料的指稱標的,它所描述的資源。以及如何描述的文字結構,也就是三元組,形式是主題-述語-物件。這篇心得是反過來寫,書中的章節則是從基礎寫到應用,讀者只要跨過前兩章純理論的內文,後面讀來就不會那麼生硬乏味。

總得來說,後設資料一書確實能讓從事數據分析職務的讀者,獲得純理論面的背景知識和學到一點富有學術感的專業術語。這點養分是否有助於未來的實務工作那就不置可否,畢竟它很明顯不是定位成一本實作的資訊工具書。額外一提,本書的譯者在文字口語化上的功力算是有待加強,許多文句讀來略為生硬,徒增這本書的閱讀門檻。


2025年6月13日 星期五

你的第一本Linux入門書:使用WSL建立Linux軟體開發與部署環境,一次學會Docker、版本控制、建立AI預訓練模型

 


對所有想要成為軟體工程師的人來說,第一個面臨的挑戰絕對是建置一個開發環境。而隨著時代的演進,最理想的作法也不斷推陳出新。對於在資訊產業從業十年以上的資深人員來說,微軟近年藉由雲端與VS Code重新奪回開發環境的市佔率,可謂王者歸來。五、六年前資訊人員人手一台蘋果筆電的盛況已不復見,如今,在Windows作業系統中使用WSL搭配VS Code來開發 AI程式,才是最夯的潮流。

《你的第一本 Linux 入門書》正是為了讓讀者快速掌握如何建置這種最新、最便捷的軟體開發環境。特別是目前仍使用macOS、VMware或VirtualBox安裝Linux環境的工程師,書中介紹的 WSL能無縫整合Windows作業系統與Linux程式運行環境,讓一般事務操作與程式執行可以在同一套作業系統中並行,可說是過去夢寐以求的理想方案。

加上VS Code安裝WSL extension後,即可直接使用 WSL 來執行各種開發環境,讓開發者更輕鬆地打造「乾淨」的程式開發平台,不再需要為了安裝大量函式庫與工具程式而把整個系統搞得亂七八糟。如果讀者已經開始投入容器化開發,本書同樣不會讓你失望。借助Docker Desktop和VS Code的Docker extension,可以建立程式容器並直接在容器中開發與執行程式碼,其體驗與WSL一樣順暢無縫。毫不誇張地說,按照書中教學建置的開發環境,不論是本機、WSL或 Docker,這三種截然不同的方式,都能將背後整合的複雜性封裝於工具之中,對工程師而言,三者在使用上幾乎感覺不到差異。

除了上述內容之外,對於WSL、Docker、Git等工具的基本操作與使用方法,書中也有清楚詳盡的教學。對於不熟悉這些工具的讀者而言,只要按部就班地翻閱本書,就能學到許多實用的基礎知識,並充分應用於後續的實務開發。針對目前最主流的Node.js、Python和PHP網頁開發,作者也貼心地提供對應的開發環境建置步驟,省去讀者自行查找與整理網路上零散資料的麻煩。本書內容豐富、處處是寶,千萬別錯過。


2025年1月27日 星期一

React 思維進化:一次打破常見的觀念誤解,躍升專業前端開發者

 



在估評、挑選網頁應用程式的技術範疇時,無庸置疑的容器化和前後端分離兩項技術已經是軟體開發業界默認的 De facto standard ,而前後端程式分離的概念與實踐更是一舉改變軟體工程師的職務劃分。以 JavaScript 為核心語言的網頁工程師,逐步變成掌握網站與行動應用開發話語權的前端工程師。隨著 Node.js 以其高效能成為網頁後端技術新竉兒,各種超越 JQuery 這個前端 JavaScript 函式庫的挑戰者們,也因為其青出於藍而大放異彩。其中 React 便是獨領風騷的一方之霸。

對於一個從事後端開發的工程師來說,學習 React 技術,目標純粹只是想減少自己對前端技術的知溝,方便未來能與前端工程師同事更容易討論、合作有前後端分離的網站專案。不過事與願違,在完全沒基礎的情況下,嘗試去搞清楚所謂的前端技術是怎麼一回事,很容易用自己瞭解的技術去推論,而有所侷限,反而看不清真相。像我一開始也鬧了個笑話,把 React 誤以為是 Java 語言裡的 Reactive 技術,還因此去研究了 Spring WebFlux。或是後來分不清 React 和 Node.js 的角色與關係,把 React 誤當成是某種 Node.js 上的框架。後面這點倒是不能笑我,畢竟 React 的開發環境太依賴 Node.js 了,幾乎所有的資料都是指導 React 開發者先安裝 Node.js。

正在苦惱如何事半功倍地學習必要的前端基礎時,React思維進化一書如天降甘霖般紓解我的煩憂。全書的目標便是替讀者們建立最正確、基礎的 React 技術觀念。也順道解答了為何 React 這樣的前端技術能將 JQuery 取而代之,而且形同水火,兩者不能並存。實際上就是 React 為了要減輕操作瀏覽器 DOM 的負擔,導入了 Virutal DOM 的設計,壓縮程式運行中所有的元件異動,只在最後階段才同步反映到瀏覽器的 DOM 上。JSX 是方便撰寫 React element 的語法蜜糖,而 React element 卻要經過 Babel 這種語法轉譯器的幫助,才能變成真正可運作的 JavaScript 程式碼。這一切的一切都有太多前情提要的背景知識,也難怪 React 不是非常好上手的程式語言。

不過 React 不好學習有另一個關鍵的原因,如果你在網路上查找 React element 的範例程式碼,肯定會找到兩種風格截然不同的東西,class component 和後來的 function component 。 書裡提出許多論證,讓讀者知道 function component 改進、消除了過去 class component 設計上的缺失。這樣的技術改版是不得不然,但這肯定是個容易讓初學者踩雷的誤區,甚至可能白費時間學到過時的 class component 開發技術。單向資料流的 prop 以及 state ,是確保 Virutal DOM 運作能正確無誤的機制,這也連帶著影響了程式碼的開發範型。從鳥瞰的角度來評論,可以說許多 React 特殊的程式碼設計風格與規範,以及搭配運作的 hooks 函式庫,都是為了達成更有效率的 DOM 更新,React 原始設計團隊,將此負擔轉嫁到工程師上,而不是開發出能簡化程式碼的一體適用執行環境。

不論是線上的 React 前端工程師,或是像我這種想對 React 多點瞭解的後端工程師。React思維進化都是值得成為第一本或是唯一一本的 React 技術指南。在擁有書中講解、介紹的背景知識後,讀者們才能更有自信,具備足夠的底氣去學習更進階的,如 Next.js 等 React 框架。而在全書的薰陶之後,即便看到前端工程師同事丟來的程式碼,相信也能略懂略懂的端詊。

2024年11月6日 星期三

科技巨頭的演算法大揭祕:資料科學家必讀的資料科學與機器學習實戰筆記

 



這本科技巨頭的演算法大揭祕基本上是幫讀者整理Netflix、Spotify、Facebook、Airbnb、Uber等知名企業,揭露它們在研發自家搜尋與推薦系統的過程中,有採用的設計與資訊技術。這也是本向大眾展示大數據與機器學習如何落地應用,產生實質商業價值的科普書。對於這些走在資通科技最前沿的大型企業,只要零點幾%的優化,對公司營運帶來的報酬可能就是數十萬美金起跳。因此天馬行空地翻轉手上的巨量資料,不停嘗試導入各種ML模型用來最佳化企業營運的各個層面,已變成它們工程團隊的DNA。他們不吝嗇透過網路文章、研究報告和論文,將九牛一毛的成果,挑選可公開於眾的技術片段,傳播到大眾面前,也藉此宣傳自家企業的技術優勢。多虧此書作者徐歆閔的消化吸收,替讀者將晦澀難懂的原文資料書寫成白話簡潔的科普文章,讓我們可以輕易地一窺各大山頭在數據應用的進展與巧思。

對於從事大數據與推薦系統開發的我而言,這本書是絕對值得收藏精讀的寶典。不過如果以實用角度來看,打個比方,它就像跟你介紹少林寺有七十二絕技、華山派有獨孤九劍、武當派有太極拳。而這些技藝都是知易行難,要花苦功練才能有所成,因此看完書懂些皮毛,讀者依舊學不會/做不出來。所以本書和多數教導實作的電腦書定位截然不同,科技巨頭的演算法大揭祕像是一本點到為止的武林秘笈。它開擴讀者的視野,點出在數據工程與推薦系統開發上,還有那些技能樹上的技術點,可以用心突破或加強的。像是向量運算、分類模型算是數據處理的入門招式,但在雜複的應用情境中依舊是不可或缺的核心項目。

個人認為企業的大數據應用發展過程可約略分成三階段。初步是開始收集、運用巨量資料,懂得利用大數據運算結果來優化資訊系統,擁有數據導向思維。接著是擁抱機器學習,打造以數據養模型的組織文化。充分將迴歸、分群、分類等各種AI模型導入到資訊系統的各個層面,達成無處不學習無處不優化的境地。最終的階段是以機器學習帶動大數據,靈活運用ML技術,甚至用來產生不存在的假資料,來泯除大數據應用的痛點(沒資料),此時會是見山不是山,大數據與機器學習再也分不清彼此。想當然而,這些科技巨頭早已達第三階段。

在電商平台開發推薦系統,某種程度上不如Netflix、Spotify這些訂閱制影音內容平台般單純。因為對於內容平台而言,只要推薦的內容是使用者真正感興趣的,一定能產生正向回饋,因為在月費制的前題下,消費任一內容對使用者來說是固定成本。電商平台則不然,商品售價、活動優惠、庫存滿足度甚至是競業的動態,都足以影響使用者對推薦內容的觀感與反應。這也是為何在推薦系統的發展大事件中,近來話語權最高的是影音內容平台Netflix(舉辨公開競賽),而不是電商龍頭Amazon,因為花費鉅資投入打造/購買一套推薦系統,對兩家公司在未來營收的影響上,不會是同一個數量級。對電商來說,一個完善的供應鏈數據平台,其重要性會遠大於擁有許多推薦模型的推薦系統。不論是數據工程、推薦系統甚至是機器學習,這些都是大數據工程師有機會施展拳腳的應用領域。它山之石可以攻錯,科技巨頭的演算法大揭祕便是扮演這樣的角色。

2024年7月27日 星期六

乾脆一次搞清楚:最完整詳細網路協定全書

 


從事程式開發多年,對於網路協定的瞭解多半僅限於第四層的TCP/UDP和第七層的HTTP,其它偏向主機網路設定的部份就是放水流。心想反正術業有專攻,日常工作時都能請專職的同仁處理,何必多花心思強記這些不常用到的網路技術。不過在開始學習如何在本地端建置Kubernetes服務時,就踢到鐵板了。因為光是想安裝一個能夠正常運作的K8S服務,就必須先搞定CRI和CNI的安裝,前者要求你熟習容器化實務,後者則希望你對網路協定與七層協定有概念。

乾脆一次搞清楚:最完整詳細網路協定全書是一本立意良好的電腦書,作者自述認為市面上的網路叢書大多著重於點對點的說明,缺乏用實務的角度切入,用口語的文字描述。導致讀者們咬著牙一頁頁翻過去,最後在工作上面臨整合性的問題分析時,依舊無法靈活應用所學得的片面知識。但我使用「立意良好」來形容本書,其實就是打了個負分,因為這本書和許多對岸出版的電腦資訊書有一樣的問題,主題相當吸引人,內容第一眼看來也十分豐富,不過在教導與介紹技術的效果上都是差強人意。書裡介紹了很多協定,但又沒針對各個主題從基礎深入著墨。當然,如果想一五一十地介紹完所有協定,我想這本書應該會厚個三五倍,正曝露出書本主題定位的問題,野心太大,成效普普。

相信這些大陸作者本身確實是學富五車,實務經驗扎實。不過在撰寫電腦書的技巧與表現上,遠遠不如台灣近來由iT邦幫忙帶起的電腦資訊書文藝復興,更別說是像日本作者擅長的圖文並茂詳解,以及我最喜愛的Manning出版社的每本是精典的超高水平。包括這本,在踩過好幾次雷之後,突然發現這些書都是深智數位出版的,而且也不像歐萊禮的書一樣有再給技術編輯審閱。當然不能武斷地說這些書不好,只能說身為讀者我是水土不服。這些對岸的電腦書,書寫方法恰如武俠小說中的各大門派的武功秘笈,讀者能吸收多少全看個人機運與修為,或許它們的目標讀者是已經擁有堅強實力的專家,但回頭又想,如果讀者已經對該主題了然於胸,那又何必翻閱這些書哩?

2024年5月12日 星期日

敏捷與Scrum軟體開發速成

 

對於軟體專案管理方法,始終沒這麼引起我的興趣。畢竟第一線研發工程師的日常,忙著找解法和實作程式碼才是工作重心,至於專案範圍、時程主要還是讓專案經理煩心。然而最近怡好參與一個採用Scrum管理方法的新專案,一開始難免一頭霧水進退失據,想來只好反求諸己,拿這本敏捷與Scrum軟體開發速成來補補知識量,以便更快調整好步調完成任務。

愛書人總會被書所關照,隨意挑選的一本Scrum著作,出乎意料地是言簡意賅的精典作品。有別於瀑布流程將軟體開發劃分成需求收集、設計、編寫程式和測試,採用一切都得事前設計的思維(BDUF-Big Design Up Front)。敏捷開發則是主張漸進的累積,以一點點的需求收集、一點點的設計、一點點的編寫程式和交付一點點的價值貫穿整個專案。敏捷價值觀如下:
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計畫

不過理想很豐滿,現實很骨感,這種顛覆傳統的專案管理手法,前提必定要出資者理解與採用,不然若是瀑布思維的客戶遇到敏捷思維的開發團隊,雙方對做完了的定義完全不同,肯定會導致衝突與齟齬。

在Scrum團隊成員分成三類角色,代表客戶提出需求與排定優先順序的產品負責人,主導Scrum流程與會議的Scrum教練,以及實際從事開發任務的團體成員。三個角色各司其職卻又要充分的協同作業以獲得團隊共識。由於敏捷開發與瀑布法的差異甚多,如果團隊成員沒被明確告知各個角色之間的責任,將會出現不可預測的管理風險。最明顯的例子就是在瀑布法位於最末端的測試,在改敏捷開發時必須融入在每個小週期內完成,甚至是連系統開發文件也被包含在一點點的設計工作裡。也因此採用敏捷開發的團隊多半也樂於懷抱測試驅動開發的程式撰寫流程。

敏捷與Scrum軟體開發速成是本值得一看的佳作,特別是想瞭解Scrum管理的獨特之處。然而這些理論與觀念,如何真正促成專案的成功,最終的變數還是執行的Scrum團隊成員。這也是Scrum管理沒有明確聲明的前提,團隊成員必須擁有相當程度的實務經驗與技術能力,因為產品負責人只負責提出客戶需求,要怎麼如質如實地打造出堅若磐石的軟體,反而是由團隊成員主動反饋、規劃和實作。軟體開發的道路上,不論是管理手法或是技術架構,本來就沒有可以一勞永逸地適應各種場合的解決方案。如果以為敏捷開發是可以確保專案開發神功護體的銀色子彈,那可誤會大了。

2023年12月22日 星期五

和艦長一起 30 天玩轉 GitLab【第二版】(iT邦幫忙鐵人賽系列書)

 

自先前看過和艦長一起30天玩轉GitLab後沒多久,這本書居然也出了第二版。但當時手上忙著研究與開發其它專案,就把翻閱第二版的事先擱下。過了大半年,近來要開始評估Jenkins和GitLab CI兩者的差異與優劣,恰好回過頭來看這本2022年翻新的第二版,感覺學到的知識又更加深刻許多。

說真的,把GitLab和Jenkins拉在一起討論,實在是小看了GitLab。有別於Jenkins是專注在CI/CD領域,如書中所述,GitLab從原本的版本控制軟體起家,在不斷發展擴充功能下,已定位自己是DevOps管理平台,參與涵蓋軟體開發過程中的各個階段。它提出了DevOps Lifecycle,定義了下面各Stage並提供相關的功能讓PM/開發人員協同作業。

Plan: 提案階段。有Issue Tracker、Issue Board和Issue Kanban等專案管理工具。
Create: 開發階段。有To-Do List和Issue List,還有Merge Request的機制,可以限制合併分支時,必須有專人核可。
Verify: 持續整合階段。藉由GitLab CI腳本實踐自動化測試/整合測試。
Package: 套件管理階段。內建的Artifact management機制,達成程式產出物管理。
Secure: 資安掃描階段。整合資安掃描軟體,進行SAST(靜態程式安全測試)、重要機敏資訊清查、程式碼品質掃描。
Release: 持續交付階段。一樣透過GitLab CI來完成自動佈署作業。
Configure: 運作環境管理階段。
Monitor: 監控階段。
Govern: 治理階段。
Manage: 管理階段。提供專案進度、工時控管等基礎的數據分析功能、圖表。

第二版的重點在於用更多的篇幅來介紹如何按步就班地利用GitLab CI撰寫出Pipeline,完成自動化編譯到佈署的一連串作業。兩相比較下,Jenkins Pipeline能做到的,基本上GitLab CI也能可以達成。巧的是兩工具都建議利用Ansible來簡化自動化佈署的難度(責任外包...XD)。而GitLab CI顯而易見的特色在於,GitLab CI是以分支的Commit來觸動Pipeline、擁有Artifact產出物管理功能、Pipeline和專案一同被版控管理等等。加上提供Mesasge Bot和API觸動Pipeline的機制、與Docker環境的高度整合,以功能完整性來看,GitLab CI確實遠優於Jenkins。當然Jenkins也有數不清的Plugins可以擴充功能,所以很難斷定那個工具是第一。

GitLab中涵蓋的軟體工程觀念實在博大精深,即便是這本和艦長一起30天玩轉GitLab第二版也僅能點到為止。對於有心的管理/開發人員,想導入更多、更完整的軟體工程來說,這本書可以是個起點,藉由GitLab這個強大的平台,漸進式的導入適合的流程與機制,以更有效率的作法產生更優質的軟體產品。

2023年8月7日 星期一

Web開發者一定要懂的駭客攻防術

 

在工作上一直都是擔任後端應用的職務,即便是目前負責的大數據與推薦引擎,依舊是歸屬在後端運算的範疇。然而在Web/HTTP影響力與日俱增的大環境下,單單開發一個API也擺脫不掉SOAP/REST這樣依附在HTTP協定的軟體架構風格。因此針對Web的安全性議題,是不分前、後端工程師都得認真學習、思考的核心知識。Web開發者一定要懂的駭客攻防術是一本堪稱完美的Web資安入門書,流暢又精確的文字內容,在資訊類型的書中相當罕見(IT類型的書多半文字用詞繞口,也會有一兩個勘誤)。全書分成必要的基礎知識和常見威脅兩部份,很完整又詳細地解說,Web應用程式是什麼?有哪些常見的漏洞?(更重要的是)如何防止哪些漏洞?

雖然駭客攻擊聽起來總是神秘莫測,令人聯想到諜報電影裡相當高上大的設備與工具。但比較落地的實情是,多數讓駭客入侵成功的程式漏洞,總數加起來不會超過手指數量(小提醒,是十)。這些可以一一細數的程式瑕疵,造成這麼多企業、個人的財務損失,起因常常是開發團隊沒有能力處理(知識不足)或低估資安漏洞的嚴重性。藉由研讀Web開發者一定要懂的駭客攻防術,足於讓從業人員認識、理解Web開發時應留意的重點,進而打造出有高防禦力的Web應用。想若所有開發者都被要求要通過此書提及的漏洞攻防國家測驗,才能從事Web程式開發職務(類似駕照考試),網路世界在這群有著資安DNA的工程師們推動之下,相信未來駭客產業將會大受打擊。

下列心得就針對第二部份常見威脅的內容,進行概略的重點整理,也方便未來回過頭來查閱。

1.注入攻擊
起因:
 程式中使用SQL語法查詢資料庫;程式中執行作業系統指令。
手法:
 利用外部可以輸入的介面或檔案上傳功能,將攻擊用的字串與檔案(WebShell)傳送到程式主機,並觸發予以攻擊
防止:
 SQL注入:唯一作法是採用參數化語句或是ORM技術。如果無法修改程式,至少要做到最小權限原則,讓程式只擁有最少的必要權限,將傷害減到最低。
 避免傳回暴露過多資訊的傳回值,例如此帳號不存在,而是採用模糊的回應,例如找不到此帳號和密碼。
 命令注入:如果無法避免支援執行作業系統指令的功能,一定要將控制字元轉義,並採用白名單限制可以被執行的命令。
 遠端程式碼執行:不要直接使用未經檢查的序列化/反序列化的資料來當輸入值,並留意伺服器軟體的漏洞,以即時修補。
 檔案上傳漏洞:最好直接將檔案放在CDN雲端服務中,將風險轉移到雲端業者。不然就確保上傳的檔案無法被執行(無執行權),並進行強制的檔案轉製(圖檔/文字檔)。

2.跨腳本攻擊(XSS)
起因:
 程式中有接受外部輸入的進入點,卻沒有將HTML控制字元轉義。
手法:
 儲存型XSS:將惡意JavaScript藉由輸入功能(例如FB、留言板),儲存到系統資料庫中。
 反射型XSS:將惡意JavaScript藉由輸入參數加在電子郵件/網頁的超連結中,誘使受害者點擊。
 DOM型XSS:將惡意JavaScript加在URL中的URI片段中,讓沒有防護JavaScript前端程式(網站本身的程式碼)誤讀並執行惡意功能。
防止:
 一律將外部輸入值進行HTML字元轉義,特別是"&'<>等控制符號。
 使用內容安全原則(CSP)HTTP回應標頭功能,可指定只允許同站台與apis.google.com的JavaScript來源(<script src="..."/>),不允許內聯(inline)的JavaScript,設定方法如下:
 Content-Security-Policy: script-src 'self' https://apis.google.com
 也可以用HTTP <meta>標題來設定,方法如下:
 <meta http-content="Content-Security-Policy" content="script-src" 'self' https://apis.google.com">
 DOM型XSS:在使用URL字串時,都要進行控制字元轉義。

3.跨站請求偽造攻擊(CSRF)
起因:
 HTTP的Cookie預設行為,是在任何請求中都會帶回指定URL同一Domain的Cookie值。
手法:
 藉由惡意超連結,讓受害者對未防護的網站執行本人未同意的操作。
防止:
 開發網站程式時要遵守REST原則,HTTP GET只用來讀取資料,不能用來新增、修改和刪除資料。
 啟動網站伺服器或軟體框架裡的防CSRF Cookie功能。
 設定Cookie為SameSite=Strict,確保同Domain的請求才能一併附帶Cookie資料
 Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Strict;
 較寬鬆的設定是SameSite=Lax,允許GET請求可以不限定來源Domain,都會附帶Cookie資料(適用於「分享」功能),其它請求一樣限定同Domain。
 Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Lax;
 對於敏感操作要求重複登入以驗證身份

4.攻擊身份驗證機制
起因:
 駭客直接以假身份操作網站系統
手法:
 暴力破解或暗網名單
防止:
 使用多因子身份驗證機制(MFA)
 實作安全的登出功能,將session Cookie清除

5.連線狀態劫持
起因:
 利用Cookie來保持連線狀態(session),卻沒有完善保護Cookie。
手法:
 駭客取得使用者的session id或session狀態,藉以偽裝成使用者的身份進行操作。
防止:
 竊取Cookie:將Cookie設定如下。HttpOnly能讓JavaScript無法讀取Cookie,Secure確保只能在HTTPS時傳送Cookie,SameSite=Lax能避免CSRF攻擊。
 Set-Cookie: session_id=278283910977381992837; HttpOnly; Secure; SameSite=Lax
 Session定置:一律不使用「URL改寫」來傳遞session id。
 脆弱Session ID:避免使用流水號式的Session ID設計,並留意Web伺服器在Session ID實作的漏洞公告。

6.規避權限管制
起因:
 系統在權限設計或目錄規劃上有缺失。
手法:
 駭客利用系統的缺失得以執行未經授權的操作或是取得未經授權的檔案。
防止:
 實作嚴謹的以角色為基礎的存取控制,避免任何垂直提權(執行高一級的操作)和水平提權(以他人身份執行操作)的攻擊。
 增加稽核軌跡。
 避免使用任何過於直覺的URL路徑與參數設計。例如/reports/<公司名稱>/<月份-年度>,讓駭客能猜測到合法路徑。
 確切設定Web伺服器,不允許顯示目錄內容、不允許利用相對路徑指定父目錄中的檔案。
 不要直接引用檔案,要自行維護一組暗碼代號用以連結到主機上的實體檔案。
 對任何有關指定檔案位置的外部參數,都要進行最嚴格的安全檢查。

7.資訊洩漏
起因:
 因疏失造成系統將機敏資訊呈現給外部使用者。
手法:
 針對系統進行探索式操作,以收集可用來進行後續攻擊的機敏資訊。
防止:
 不使用系統預設的回應標題(像預設的4xx、5xx頁面)。
 使用未帶程式副檔名(.php、jsp、aspx)的簡潔URL。
 Cookie的健值不要用預設值(JESSIONID)。
 不要在正式環境中顯示詳細的錯誤描述。
 壓縮或模糊化JavaScript程式。
 清理前端程式中不必要的註解和程式碼。

8.加解密機制
起因:
 未使用加密通訊協定。
手法:
 竊聽網路封包。
防止:
 一律使用HTTPS。

9.第三方元件
起因:
 使用到不安全的第三方元件。
手法:
 針對已知的元件漏洞攻擊。
防止:
 留意第三方元件安全公告,及時更新。
 保護好第三方服務的系統金鑰。

10.XML攻擊
起因:
 DTD的設計漏洞。
手法:
 藉由內聯的DTD宣告,讓系統主機資源耗盡。
 在DTD宣告外聯以下載惡意檔案。
 利用XML解析失敗時會顯示檔案內容的特性,指定主機上的機敏檔案。
防止:
 關閉DTD內聯功能。
 設定防火牆限制外聯對象。
 盡量不使用XML,非得使用時要再三確保XML解析器的安全設定已就位。

2023年3月25日 星期六

下世代超前佈署:用Zabbix全面監管巨量伺服器

 

在台灣中小企業為主的職場環境下,程式人員提供「一條龍」式的IT技能服務,是普遍常見的工作樣態。從設計構思、開發實作到後續的營運維護,如果不善用工具減輕自身的負擔,想憑著一腔熱血硬撐到底,結果不是爆肝就是離職單吧。IT系統看似五花八門,追根究底來說不外乎由網路設備、伺服器、中介軟體以及應用程式所組成。藉由監控系統適時地在每一層設定監管項目,營運人員將鉅細靡遺觀察IT服務運作的狀態。開碼的監控系統產品很多,而本書介紹的「Zabbix」是相當強大、易用的選擇。

從「設定主機」的步驟開始,使用者就體會到Zabbix包羅萬象的監控能力,主機(Host)指的是任何有連網的可被監控設備,除了一般的電腦/伺服器外,也包含各式網路設備。監控使用的通訊協定,從網路常見的SNMP(Simple Network Management Protocol)、硬體週邊的IPMI(Intelligent Platform Management Interface),到真正發揮出Zabbix驚人威力的Zabbix Agent/Agent2,選項一應俱全。面對最常見的伺服器硬體監控需求,藉由範本(Template)檔的協助,使用者將可快速地將CPU、記憶體、磁碟、網路卡等重點項目設定完成。尤其是自Zabbix 3.4版開始支援的LLD(Low-Level Discovery),自動搜尋伺服器裡的磁碟、網卡名稱帶入監控項目,讓管理者免於一台台手動調整監控項目裡的參數值,讓我這個一直在用Zabbix 2.x版的老用戶,感到這次升級值回票價。

因為範本檔和LLD兩者結合後的強大威力,一般常見的監控標的都可以既有的範本檔中獲得滿足,就連較新穎的HAProxy、Redis等中間層軟體,也都有可以參照的案例可以依循。書中也特別安排一個專章,介紹包含TCP、Nginx、PHP-FPM、MySQL、IPMI、磁碟陣列卡、路由器、VMware、RabbitMQ、Elasticsearch、Kafka、Redis、Oracle、WebLogic、SQL Server、HTTPS。監控項(Item)的實践Zabbix支援18種方法!加上透過Zabbix Agent的自訂使用者參數(UserParameter)功能,應該沒有任何無法監控的項目,唯一的限制就是使用者的想像力。針對非常客製化的應用服務層(自製系統的營運狀態),一樣是拿出傳家寶刀UserParameter就可以迎刃而解。API層的監控則是利用HTTP方法,如此一來同時擁有簡化設定、減少客製化的優點。雖然Zabbix也擁有對伺服器記錄檔的文字資料收集/監控能力,不過功能非常陽春,因此對於這種需求還是用Splunk或ELK這種專門工具比較理想。

和Cacti使用集中式主機輪詢的被動式監控不同,藉由Zabbix Agent的協助下,Zabbix可以採用主動式監控,來達成監控巨量標的的任務。按書中所言,在配置有適當主機規格的前提下,單一台Zabbix Server即可監控上千台伺服器。更別說如果再加上Zabbix Proxy的分散式監控架構,讓異地機房的監控負擔由Proxy先處理後傳回Zabbix Server整合。Zabbix的監控能力,足以滿足九成以上台灣企業的IT規模。簡單一句話:好東西,不學嗎?

2023年2月18日 星期六

玩真的!Git ? GitHub 實戰手冊 - coding 實境、協同開發、雲端同步,用最具臨場感的開發實例紮實學會!



Git工具在軟體版本管理領域中的地位我想已經不用多言,基本上除非是上古時期的恐龍工程師,絕大多數的碼農都至少熟悉一種版控工具,而Git是其中的佼佼者。它被廣泛地整合到各種IDE(整合開發環境)中,也有數種方便好用的GUI(圖形使用者介面)工具,一但有協同開發的需要,Git對軟體工程師而言是非常友善的選項。

話說回來,也因為工具整合的太好,常見的操作根本用不著親自下指令,所以許多人連基本的Git指令都沒打過。更別說一些合併失敗的異常情況,是需要瞭解Git的設計與觀念才能迅速、正確的排除。如果沒打好基礎,偏偏又在專案Deadline前遇到,那可真的會讓人冷汗直冒。而這本「玩真的!Git ? GitHub 實戰手冊」正是以實例帶領讀者利用最符合職場開發情境的範例,完成一項又一項具體的Git任務,讓你從初學邁到進階的一本佳作。

不論是全域參數檔設定、修改/壓縮commit註解和運用stash暫存區等,這些被一般書籍視為「進階」的Git功能,書中都用簡明扼要的描述並配合直接的例子讓讀者心領神會,對比其它以Git為主題的書,這本的CP值是遙遙領先。最終章更是將使用Git時常困擾開發者的一些疑難雜症條例出來,一一提出具體解法。這本書放在案頭,可以讓你有如服下定心丸般,盡情使用Git來滿足協同開發與版本控制的需求。