Originally published at https://somprasongd.work/blog/docker/docker-image-for-go

เมื่อพัฒนาแอปพลิเคชันด้วยภาษา Go หนึ่งในจุดเด่นที่สำคัญคือการสร้างไฟล์ไบนารีแบบ static ทำให้เหมาะอย่างยิ่งสำหรับนำไปบรรจุใน Docker container ที่มีขนาดเล็กและปลอดภัย ซึ่ง Alpine Linux เป็นฐานที่คนนิยมใช้เพราะขนาดเล็กและมีแพ็กเกจพื้นฐานเพียงพอสำหรับงานส่วนใหญ่

แต่การจะทำให้ container ขนาดเล็กและพร้อมใช้จริงใน production ต้องเข้าใจประเด็นสำคัญทั้งในแง่ของ build, dependency, และการจัดการ image ให้มีความเสถียรและปลอดภัย

ปิด cgo (CGO_ENABLED=0) เพื่อสร้าง static binary

โดยปกติ Go จะเปิดใช้ cgo เป็นค่าเริ่มต้นหากโค้ดมีการเรียกไลบรารี C หรือใช้ฟังก์ชันมาตรฐานบางส่วนที่อ้างอิง libc ซึ่งอาจทำให้ไฟล์ไบนารีต้องพึ่งพา shared library ภายนอก เช่น glibc หรือ musl

เมื่อใช้ Alpine ซึ่งใช้ musl libc แทน glibc ปัญหาที่พบบ่อยคือไฟล์ไบนารีที่พึ่ง glibc จะรันไม่สำเร็จ หากต้องการความแน่นอนว่ารันได้ทุกที่บน Linux base image ควรตั้ง CGO_ENABLED=0 เพื่อให้ Go สร้างไฟล์ไบนารีที่ลิงก์แบบ static ทั้งหมด ลดปัญหา dependency ภายนอก

ตัวอย่างที่นิยมคือ

ENV CGO_ENABLED=0

ลดขนาดไฟล์ด้วย ldflags “-s -w”

ตัวเลือก -ldflags="-s -w" เป็นอีกเทคนิคที่ใช้กันทั่วไปเพื่อลดขนาดไฟล์ที่ได้จาก go build

• s จะตัด symbol table ซึ่งไม่จำเป็นต่อการรันจริง
• w จะตัดข้อมูลสำหรับการ debug (DWARF)

ผลคือขนาดไฟล์จะลดลงได้หลาย MB แต่ข้อควรระวังคือ หากต้องใช้เครื่องมือ debug เช่น Delve ข้อมูลเหล่านี้จะหายไป ทำให้ debug ได้ลำบากขึ้น เทคนิคนี้จึงเหมาะสำหรับ build ไบนารีที่ใช้จริงใน production เท่านั้น

ทำไมไม่ควรใช้ alpine:latest

หลายคนมักเขียน Dockerfile ว่า FROM alpine:latest เพราะง่าย แต่ในทางปฏิบัติ นี่เป็นสิ่งที่ควรหลีกเลี่ยง เนื่องจาก tag latest ไม่ได้ผูกกับ version ใด ๆ แบบตายตัว ภายใน repository อาจอัปเดตเมื่อใดก็ได้โดยไม่ประกาศล่วงหน้า ซึ่งทำให้ build ครั้งถัดไปอาจได้ base image ที่ไม่เหมือนเดิมและอาจเกิดปัญหาใหม่โดยไม่รู้ตัว

แนวทางที่ควรทำคือระบุเวอร์ชันให้ชัดเจน เช่น FROM alpine:3.22 เพื่อให้แน่ใจว่าผลลัพธ์ reproducible และ rollback ได้ง่ายหากเกิดปัญหา

ใช้ Multi-Stage Build เพื่อลดขนาดและจัดการได้ง่าย

Dockerfile สำหรับ Go ที่ดีควรแยกขั้นตอน build ออกจากขั้นตอน runtime โดยใช้ multi-stage build ขั้นแรกใช้ image golang:<version>-alpine สำหรับ compile โค้ด ขั้นถัดไปใช้ alpine:<version> หรือแม้แต่ scratch เพื่อลดขนาด image

ตัวอย่างโครงสร้าง

# Build Stage
FROM golang:1.24-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
ENV CGO_ENABLED=0 GOOS=linux GOARCH=amd64
ARG VERSION=latest
RUN go build -ldflags="-s -w -X 'main.Version=${VERSION}'" -o /app/app ./cmd/api/main.go
# Final Stage
FROM alpine:3.22
RUN apk add --no-cache ca-certificates tzdata \
    && addgroup -S appgroup \
    && adduser -S appuser -G appgroup
WORKDIR /app
COPY --from=builder /app/app .
USER appuser
EXPOSE 8080
ENTRYPOINT ["./app"]

ใช้ Non-Root User

อีกหนึ่งจุดที่หลายคนมองข้ามคือ user ที่ container ใช้รันโปรเซส เริ่มต้น container จะรันด้วย root ซึ่งถ้าเกิดช่องโหว่ ผู้โจมตีอาจใช้สิทธิ root ภายใน container เพื่อโจมตีต่อได้ง่าย

วิธีแก้คือสร้าง user สิทธิจำกัด แล้วสั่งให้ container รันด้วย user นี้แทน การเพิ่มบรรทัด adduser และ USER ใน Dockerfile เป็นวิธีปฏิบัติมาตรฐานที่ช่วยปิดความเสี่ยงนี้ได้ดี

ENTRYPOINT vs CMD

หลายคนสับสนระหว่าง ENTRYPOINT และ CMD ว่าควรใช้แบบไหน ต่างกันอย่างไร

• ENTRYPOINT ใช้กำหนด คำสั่งหลัก ที่ container ต้องรันเสมอ ไม่ว่าผู้ใช้จะสั่ง docker run พร้อม argument อะไร คำสั่งนี้จะถูกเรียกเสมอ โดย argument ที่ตามมาจะถูกต่อท้าย
• CMD ใช้กำหนด default arguments ถ้า docker run ไม่ได้ระบุ argument ใหม่ ระบบจะใช้ค่าใน CMD แทน แต่ถ้าผู้ใช้ระบุ argument ใหม่ทั้งหมด CMD จะถูกแทนที่ทันที

ตัวอย่างเช่น

ENTRYPOINT ["./app"]
CMD ["--port=8080"]

กรณีนี้ หากรัน docker run myapp จะได้ ./app --port=8080 ถ้ารัน docker run myapp --help จะได้ ./app --help

การใช้ ENTRYPOINT แบบ exec form (["./app"]) ยังช่วยให้โปรเซสของเราทำงานเป็น PID 1 โดยตรง ทำให้จัดการ signal ได้ถูกต้อง โดยเฉพาะ SIGTERM ซึ่งสำคัญต่อการทำ graceful shutdown ใน production

สรุปแนวทาง Production Docker Image สำหรับ Go

• ปิด cgo (CGO_ENABLED=0) เพื่อสร้างไฟล์ static
• ใช้ ldflags="-s -w" เพื่อลดขนาดไฟล์
• ระบุ base image version ชัดเจน เช่น alpine:3.18 อย่าใช้ latest
• แยกขั้น build ออกจากขั้น runtime ด้วย multi-stage build
• สร้าง non-root user เพื่อลดความเสี่ยง
• ใช้ ENTRYPOINT เพื่อกำหนด command หลัก และ CMD เพื่อกำหนด default arguments

แนวทางทั้งหมดนี้จะช่วยให้ได้ Docker Image ที่ขนาดเล็ก เสถียร ปลอดภัย และจัดการได้ง่ายจริงในงาน production

ในการพัฒนาระบบที่เกี่ยวข้องกับข้อมูลสำคัญ เช่น การเงิน หนึ่งในสิ่งที่ขาดไม่ได้คือการใช้ Database Transaction เพื่อให้มั่นใจว่าข้อมูลจะถูกจัดการอย่างถูกต้องและปลอดภัย โดยเฉพาะในสถานการณ์ที่มีหลายคำสั่ง SQL ทำงานร่วมกัน เช่น “การโอนเงิน” ที่ต้องอัปเดตยอดเงินสองบัญชีพร้อมกัน

ในบทความนี้ เราจะพาคุณเข้าใจว่าเหตุใดการใช้ Transaction จึงสำคัญ ผ่านการเรียนรู้แนวคิด ACID, Lock, และ Deadlock ด้วยตัวอย่างจากการโอนเงินระหว่างบัญชีด้วย PostgreSQL

โครงสร้างฐานข้อมูล: accounts และ transactions

CREATE TABLE public.accounts (
    id serial4 NOT NULL,
    "name" text NOT NULL,
    balance numeric NOT NULL,
    CONSTRAINT accounts_pkey PRIMARY KEY (id)
);

CREATE TABLE public.transactions (
    id serial4 NOT NULL,
    from_account_id int4 NULL,
    to_account_id int4 NULL,
    amount numeric NOT NULL,
    created_at timestamp DEFAULT now() NULL,
    CONSTRAINT transactions_pkey PRIMARY KEY (id),
    CONSTRAINT transactions_from_account_id_fkey FOREIGN KEY (from_account_id) REFERENCES public.accounts(id),
    CONSTRAINT transactions_to_account_id_fkey FOREIGN KEY (to_account_id) REFERENCES public.accounts(id)
);

ปัญหา: การโอนเงินโดยไม่ใช้ Transaction

สมมุติว่าเราต้องโอนเงิน 500 บาทจากบัญชี A ไปยังบัญชี B โดยใช้คำสั่ง SQL ต่อไปน

UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

ถ้าเกิดเหตุขัดข้องหลังอัปเดตบัญชี A แล้ว (เช่น network error หรือ crash) แต่ยังไม่ทันเพิ่มเงินให้บัญชี B — เงิน 500 บาทจะ “หายไปจากระบบ” ซึ่งเป็นปัญหาหนักมากในระบบการเงิน

วิธีแก้: ใช้ Database Transaction

BEGIN;

UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);

COMMIT;

หากคำสั่งใดล้มเหลว PostgreSQL จะไม่ COMMIT และเราสามารถ ROLLBACK เพื่อยกเลิกทุกคำสั่งที่ทำไปแล้ว ทำให้ข้อมูลไม่เสียหาย

เข้าใจ ACID: หัวใจของ Transaction

ACID คือคุณสมบัติหลักของ Database Transaction ที่ทำให้ข้อมูลเชื่อถือได้ ซึ่งย่อมาจาก

• Atomicity — ทุกคำสั่งใน transaction ต้องสำเร็จทั้งหมด หรือไม่สำเร็จเลย
• Consistency — หลัง transaction สำเร็จ ฐานข้อมูลยังคงถูกต้องตามกฎ เช่น balance ≥ 0
• Isolation — แต่ละ transaction ไม่รบกวนกันระหว่างทำงานพร้อมกัน
• Durability — เมื่อ COMMIT แล้ว ข้อมูลจะถูกบันทึกถาวร แม้ระบบดับ

ตัวอย่าง: หากมีคนโอนเงินจากบัญชีเดียวกันสองคนพร้อมกัน PostgreSQL ต้องมั่นใจว่าไม่มีการขัดแย้ง หรือข้อมูลผิดเพี้ยน เช่นเงินติดลบ

การล็อกข้อมูล (Database Lock)

PostgreSQL จะล็อก row-level อัตโนมัติเมื่อมี UPDATE:

UPDATE accounts SET balance = balance - 500 WHERE id = 1;

แถวของบัญชี id = 1 จะถูกล็อกไว้จนกว่า transaction จะจบ เพื่อป้องกันไม่ให้ transaction อื่นเข้ามาแก้ไขบัญชีเดียวกันพร้อมกัน

สถานการณ์: select ก่อน update

แต่ในกรณีที่ใน application logic มีการดึงข้อมูล (select) ขึ้นมาก่อน แล้วทำการแก้ไขค่า เสร็จแล้วบันทึกกลับไปในฐานข้อมูล (update) แล้วเกิด transaction เข้ามาแก้ไขบัญชีเดียวกันพร้อมกัน เช่น

-- Transaction A
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1;
id|name|balance|
--+----+-------+
 1|A   |   1000|

UPDATE accounts SET balance = 1000 - 500 WHERE id = 1;
COMMIT;
-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1;
id|name|balance|
--+----+-------+
 1|A   |   1000|
UPDATE accounts SET balance = 1000 - 500 WHERE id = 1;
COMMIT;

ในสถานการณ์นี้จะทำให้ค่า balance ผิด แทนที่จะเหลือ 0 แต่กลับเหลือ 500 แทน

วิธีแก้: ใช้ SELECT FOR UPDATE เพื่อล็อกก่อน

-- Transaction A
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
id|name|balance|
--+----+-------+
 1|A   |   1000|

UPDATE accounts SET balance = 1000 - 500 WHERE id = 1;
COMMIT;
-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
-- จะหยุดรอจนกว่า Transaction A จะ COMMIT หรือ ROLLBACK
id|name|balance|
--+----+-------+
 1|A   |   500|
UPDATE accounts SET balance = 500 - 500 WHERE id = 1;
COMMIT;

Deadlock: ล็อกขัดกันเอง

สถานการณ์ที่ 1:

• Transaction A: โอน A ➜ B
• Transaction B: โอน B ➜ A

-- Transaction A
BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
-- รอ เพราะ lock จาก Transaction B

-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 2;
UPDATE accounts SET balance = balance + 300 WHERE id = 1;
-- ERROR: deadlock detected

สถานการณ์ที่ 2:

ถ้า INSERT ไปยัง transactions ซึ่งมี Foreign Key อ้างถึง accounts.id และหากมีอีก transaction กำลัง UPDATE accounts อยู่ อาจเกิด Deadlock ได้

เช่น สมมุติให้เปลี่ยนลำดับให้บันทึก transactions ก่อน แล้วมาดึงข้อมูลข้อมูล accounts ก่อน update

-- Transaction A
BEGIN;

INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);
SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
-- หยุดรอ เพราะ INSERT INTO transactions จาก Transaction B


-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);
SELECT id, "name", balance FROM accounts WHERE id = 1 FOR UPDATE;
-- ERROR: deadlock detected

จากสถานการณ์ที่ยกตัวอย่างมา ทั้งสอง transaction จะล็อกบัญชีฝั่งของตนเองก่อน แล้วรอกันข้าม — ทำให้เกิด Deadlock PostgreSQL จะเลือก kill transaction ใด transaction หนึ่งเพื่อยกเลิก

วิธีป้องกัน Deadlock

• ล็อก row ตามลำดับเสมอ
  ใช้ ORDER BY id เพื่อให้ทุก transaction ล็อกบัญชีตามลำดับเดียวกัน เช่น id จากน้อยไปมาก
• ล็อก row ก่อนอัปเดตด้วย FOR NO KEY UPDATE
  หากไม่ล็อก row ล่วงหน้า PostgreSQL จะพยายามล็อกเองในตอนที่ INSERT ไปยัง transactions ซึ่งมี Foreign Key อ้างถึง accounts.id
  หากอีก transaction กำลัง UPDATE accounts อยู่ อาจเกิด Deadlock ได้
  FOR NO KEY UPDATE คือระดับ lock ที่
  - ป้องกันการ update, delete หรือ insert ที่อ้าง foreign key
  - เบากว่า FOR UPDATE แต่ปลอดภัยสำหรับกรณีแบบนี้
  - เหมาะสำหรับ row ที่เราจะอัปเดต (แต่ไม่เปลี่ยนค่า primary key)
• ควร UPDATE accounts ก่อน แล้วค่อย INSERT transactions
  ช่วยลดความเสี่ยงในการเกิด Deadlock เพราะว่าหากคุณ INSERT ก่อน และมี Foreign Key ไปที่ accounts → PostgreSQL จะพยายามล็อก row เหล่านั้นก่อน ถ้าคำสั่ง UPDATE accounts มาทีหลัง อาจเกิด Deadlock ได้ (โดยเฉพาะถ้าอีก transaction ล็อกกลับกัน)

ตัวอย่าง

-- Transaction A
BEGIN;

-- 1. ล็อกบัญชีล่วงหน้าเพื่อลดโอกาส deadlock
SELECT id FROM accounts
WHERE id IN (1, 2)
ORDER BY id
FOR NO KEY UPDATE;
-- 2. อัปเดตยอดเงิน
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
-- 3. บันทึกธุรกรรม
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (1, 2, 500);
COMMIT;
-- Transaction B (เกิดขึ้นพร้อมกัน)
BEGIN;
SELECT id FROM accounts
WHERE id IN (1, 2)
ORDER BY id
FOR NO KEY UPDATE;
-- รอจนกว่า Transaction A จะถูก COMMIT หรือ ROLLBACK
UPDATE accounts SET balance = balance - 300 WHERE id = 2;
UPDATE accounts SET balance = balance + 300 WHERE id = 1;
INSERT INTO transactions (from_account_id, to_account_id, amount)
VALUES (2, 1, 300);
COMMIT;

เปรียบเทียบระดับ Lock (ใน SELECT … FOR …)

• FOR UPDATEอัปเดต row ห้ามใคร update/delete แถวนี้
• FOR NO KEY UPDATEอัปเดต row (ไม่แตะ key)ห้าม insert ที่อ้างถึง row นี้ (FK)
• FOR SHAREอ่านอย่างเดียวห้ามใคร delete หรือ update แถวนี้
• FOR KEY SHAREอ่านพร้อมอ้าง FKห้ามใครเปลี่ยน primary key หรือ delete

สรุป

การใช้ Database Transaction เป็นสิ่งสำคัญอย่างยิ่งในระบบที่ต้องการความถูกต้องของข้อมูล โดยเฉพาะระบบการเงิน โดย PostgreSQL มีคุณสมบัติรองรับ ACID อย่างครบถ้วน พร้อมระบบ Lock และกลไกจัดการ Deadlock อัตโนมัติ

หากละเลยการใช้ Transaction อาจนำไปสู่ความเสียหายทางข้อมูล และความไม่ถูกต้องที่ยากจะแก้ไขภายหลัง

ในระบบที่ออกแบบแบบ DDD (Domain-Driven Design) หรือ Modular Monolith หลายคนมักเริ่มต้นด้วยการเขียนโค้ดในรูปแบบ Imperative Style — ซึ่งตรงไปตรงมาแต่ coupling สูง และแยก concern ได้ไม่ชัดเจน

ยกตัวอย่างเช่น ใน CustomerService ที่รับผิดชอบสร้างลูกค้าใหม่ เราอาจเขียน logic ประมาณนี้

if err := h.custRepo.Create(ctx, customer); err != nil {
 return err
}

// ส่งอีเมลต้อนรับทันที
if err := h.notiSvc.SendEmail(customer.Email, "Welcome!", ...); err != nil {
 return err
}

แม้โค้ดนี้จะดูเรียบง่าย แต่จริงๆ แล้วมันแฝงปัญหาหลายอย่างไว้ เช่น

• Coupling สูง: Command Handler รู้จัก Service สำหรับส่งอีเมลโดยตรง
• ยากต่อการขยาย/ปรับปรุง: หากในอนาคตอยากส่ง SMS หรือบันทึก event log เพิ่มเติม ต้องแก้ handler ตรงนี้
• ยากต่อการทดสอบ: การ mocking พฤติกรรมที่เกิด “หลัง” การสร้าง customer ทำได้ยาก

ย้าย Logic ที่ไม่ใช่ Core Concern ออกด้วย Event

ทางออกที่ดีกว่า คือการใช้แนวคิด Domain Events และ Integration Events เพื่อแยก concern ต่างๆ ออกจาก core business logic

Domain Event คืออะไร?

Domain Event คือสิ่งที่เกิดขึ้นใน domain ของเรา เช่น CustomerCreated, OrderCancelled เป็นต้น - โดย publish และ handle อยู่ภายใน module เดียวกัน

เช่น เมื่อสร้าง Customer สำเร็จ ก็สามารถเพิ่ม logic เช่นนี้

customer.AddDomainEvent(CustomerCreated{
 ID:    customer.ID,
 Email: customer.Email,
})

จากนั้น ระบบจะมี Domain Event Dispatcher ที่ทำหน้าที่ตามหา handler ที่เหมาะสมมาทำงานต่อ — โดยไม่กระทบ core logic

Integration Event คืออะไร?

เมื่อมีบาง domain event ที่เราต้อง “แจ้ง” ไปยัง ระบบอื่น หรือ module อื่น เช่นการส่งอีเมล, เขียน log audit, หรือแจ้งผ่าน Kafka — เราจะ แปลง Domain Event เป็น Integration Event แล้วค่อยส่งออกแบบ async

ตัวอย่าง

type CustomerCreatedDomainEventHandler struct {
 eventBus EventBus
}

func (h *CustomerCreatedDomainEventHandler) Handle(ctx context.Context, evt CustomerCreated) error {
 // แปลงเป็น Integration Event
 return h.eventBus.Publish(ctx, CustomerCreatedIntegrationEvent{
  CustomerID: evt.ID,
  Email:      evt.Email,
 })
}

สรุปข้อดีของการใช้ Event-Based Approach

• แยก business logic ออกจาก infrastructure concern
• ลด coupling ระหว่าง module และ service ต่างๆ
• เปิดทางสู่ scalability และ async processing
• ง่ายต่อการทดสอบ และรองรับ use-case ใหม่ๆ โดยไม่แก้ core logic

สุดท้าย

การเปลี่ยนจากแนวทาง imperative ที่ทำทุกอย่างตรงๆ ไปสู่ event-driven ไม่ได้หมายความว่าคุณต้องเปลี่ยนทั้งหมดในคราวเดียว — แต่การเริ่ม “แยก concern” ให้ชัดเจนมากขึ้น จะช่วยให้ระบบของคุณ flexible, maintainable และรองรับการเติบโตได้ดียิ่งขึ้น

ในการออกแบบซอฟต์แวร์ สถาปัตยกรรมเป็นหนึ่งในปัจจัยสำคัญที่มีผลต่อความสามารถในการขยายตัว (scalability) การดูแลรักษา (maintainability) และประสิทธิภาพ (performance) ของระบบ แนวทางหลัก ๆ ในการออกแบบระบบ ได้แก่ Monolith, Modular Monolith, Microservices, และ Distributed Monolith ในบทความนี้ เราจะมุ่งเน้นไปที่ Modular Monolith ซึ่งเป็นทางเลือกที่สมดุลระหว่างความง่ายของ Monolith และความยืดหยุ่นของ Microservices

ทำความเข้าใจภาพรวมของสถาปัตยกรรมต่าง ๆ

ก่อนที่เราจะเจาะลึกถึง Modular Monolith มาดูภาพรวมของแต่ละสถาปัตยกรรมที่แสดงในรูป:

• Monolith: ระบบทั้งหมดรวมอยู่ในโค้ดเบสเดียวและ deploy เป็นหน่วยเดียวกัน (single deployment unit) ทำให้พัฒนาง่ายแต่ขยายระบบลำบาก
• Microservices: แต่ละโมดูลแยกออกเป็นบริการอิสระ (independent services) สามารถพัฒนา ทดสอบ และ deploy แยกจากกันได้
• Distributed Monolith: ระบบถูก deploy ออกเป็นหลายหน่วยแต่ยังคงมีการพึ่งพากันอย่างแน่นหนา ทำให้ขยายตัวยาก
• Modular Monolith: โค้ดถูกแยกเป็นโมดูลภายในระบบเดียวกัน มีขอบเขตที่ชัดเจนแต่ยังคง deploy เป็นหน่วยเดียว

Modular Monolith คืออะไร?

Modular Monolith เป็นสถาปัตยกรรมที่พยายามนำข้อดีของ Monolith และ Microservices มารวมกัน โดยมีลักษณะดังนี้:

1. การแยกโมดูลภายในระบบเดียวกัน: ระบบถูกแบ่งเป็นโมดูลแยกจากกัน (เช่น Payments, Bookings, Reviews) โดยแต่ละโมดูลมีขอบเขตที่ชัดเจนและสื่อสารกันผ่าน API ภายใน
2. Deployment เป็นหน่วยเดียว: แม้ว่าโมดูลจะแยกกันชัดเจน แต่การ deploy ยังคงอยู่ในรูปแบบของแอปพลิเคชันเดียว
3. การรักษาความสมบูรณ์ของข้อมูล (Data Integrity): ต่างจาก Microservices ที่แต่ละบริการมีฐานข้อมูลของตัวเอง Modular Monolith มักใช้ฐานข้อมูลเดียวกัน แต่แบ่ง schema หรือใช้แนวทาง Database per Module
4. การสื่อสารภายในที่มีประสิทธิภาพ: โมดูลสามารถเรียกใช้กันโดยตรงผ่าน method calls หรือภายใน memory แทนที่จะต้องใช้ HTTP/gRPC เหมือนใน Microservices ทำให้ลด latency ลง
5. ง่ายต่อการเปลี่ยนไปใช้ Microservices: Modular Monolith ช่วยให้ทีมพัฒนาออกแบบระบบเป็นโมดูลตั้งแต่แรก ทำให้สามารถแยกโมดูลออกมาเป็น Microservices ได้ง่ายขึ้นในอนาคต

ข้อดีของ Modular Monolith

• ลดความซับซ้อนของการ Deploy: เนื่องจากทุกโมดูลอยู่ในระบบเดียว การจัดการ deployment ง่ายกว่าการต้อง deploy หลาย services
• พัฒนาง่ายและมีประสิทธิภาพสูง: นักพัฒนาสามารถทำงานใน codebase เดียวกัน โดยไม่ต้องเสียเวลาในการตั้งค่า service-to-service communication เหมือนใน Microservices
• รักษาความสม่ำเสมอของข้อมูลได้ง่าย: ใช้ฐานข้อมูลเดียวกัน ทำให้ลดปัญหา data inconsistency ที่มักเกิดขึ้นใน Microservices
• ลด Overhead ของ Infrastructure: ไม่ต้องจัดการระบบ orchestration ซับซ้อนเช่น Kubernetes หรือ API Gateway เหมือนใน Microservices
• รองรับการขยายในอนาคต: ถ้าจำเป็น สามารถแยกโมดูลออกมาเป็น Microservices ได้โดยไม่ต้องรื้อโครงสร้างระบบทั้งหมด

ข้อเสียของ Modular Monolith

• การ Deploy ยังต้องทำทั้งระบบ: แม้จะมีโมดูลแยกกัน แต่เมื่อมีการเปลี่ยนแปลงในโค้ด ระบบทั้งหมดต้องถูก deploy พร้อมกัน
• อาจนำไปสู่ Distributed Monolith ถ้าออกแบบไม่ดี: หากโมดูลต่าง ๆ ถูก deploy แยกกันโดยที่ยังคงมีการพึ่งพากันสูง อาจทำให้เกิด Distributed Monolith ซึ่งมีปัญหาที่ยากต่อการจัดการ
• ข้อจำกัดของ Scaling: ไม่สามารถ scale แต่ละโมดูลแยกจากกันได้ง่ายเหมือนใน Microservices

Modular Monolith เหมาะกับใคร?

• ทีมที่ต้องการสร้างระบบที่มี ขอบเขตโมดูลชัดเจน แต่ยังไม่ต้องการความซับซ้อนของ Microservices
• องค์กรที่ต้องการลด Overhead ของ Infrastructure และมีทีมขนาดเล็กถึงกลาง
• ระบบที่ยังไม่ต้องการ scale แบบอิสระในแต่ละโมดูล แต่ต้องการเตรียมความพร้อมสำหรับอนาคต

สรุป

Modular Monolith เป็นแนวทางที่อยู่ระหว่าง Monolith และ Microservices ซึ่งให้ความสมดุลระหว่างความง่ายในการพัฒนาและการแยกโมดูลที่ชัดเจน เป็นตัวเลือกที่เหมาะสมสำหรับทีมที่ต้องการแยกโมดูลแต่ยังไม่ต้องการความซับซ้อนของ Microservices อย่างไรก็ตาม การออกแบบให้โมดูลมีขอบเขตที่ชัดเจนและลดการ coupling ระหว่างโมดูลเป็นสิ่งสำคัญ เพื่อป้องกันการกลายเป็น Distributed Monolith โดยไม่ตั้งใจ

หากระบบของคุณเติบโตขึ้นและต้องการขยายตัว Modular Monolith จะช่วยให้สามารถเปลี่ยนไปใช้ Microservices ได้ง่ายขึ้น ทำให้เป็นแนวทางที่ได้รับความนิยมในการออกแบบระบบยุคใหม่

บทความนี้จะพาคุณไปรู้จักกับภาษา Go ตั้งแต่ขั้นพื้นฐานจนถึงแนวคิดขั้นสูง โดยครอบคลุมหัวข้อสำคัญ ได้แก่

• เริ่มต้นใช้งาน
• พื้นฐานภาษา Go
• ชนิดของข้อมูลใน Go
• ออกแบบโค้ดให้ยืดหยุ่นด้วย Interface
• ทำความรู้จักกับ Generic ในภาษา Go
• การทำงานแบบ Concurrency
• การจัดการข้อผิดพลาด (Error Handling)
• Unit Testing
• การใช้งานฟังก์ชันขั้นสูง
• การใช้ Context ใน Go
• การทำงานกับ JSON

อ่านเพิ่มเติมได้ที่ https://somprasongd.work/blog/go/go-fundamentals

#2 มาฝึกเข้าเต้ากันเถอะ

โอบกอดแรก

สัมผัสแรกระหว่างแม่ลูก คือการที่ พยบ. พาอัลตร้ามาเข้าเต้าแม่ปุ๊ เนื่องจากแม่ต้องนอนนิ่งๆ พยบ. จึงต้องค่อยช่วยให้อัลตร้าเข้าเต้าเพื่อกระตุ้นน้ำนม วันแรกพยายามกันอยู่ 5 รอบ แต่ยังถือว่าไม่ผ่่่านคะแนนแต่ละรอบได้ไม่เคยเกิน 5/10 พยบ.จึงขอให้แม่พักผ่อนตอน 3 ทุ่ม และพาอัลตร้าไปดูแลต่อเอง

โดยพยาบาลขอเสริมนมผงถ้าอัลตร้าหิวมาก ทั้งคืนได้ไป 3 ครั้ง ครั้งละ 10 ml

ฟ้าหลังฝนสวยงามเสมอ

วันที่ 2 พยบ. นัดไว้ 7 โมงเช้า แต่รอแล้วยังไม่มา แม่ปุ๊ร้อนใจให้พ่อโทรตาม กว่าจะมาก็ 7:30 น. แล้ว แถมได้นมเสริมมาแล้ว 10 ml หลับปุ๋ยมาเลย แม่ปุ๊ถึงกับร้องไห้ที่ไม่ได้ให้นมอัลตร้า

เริ่มต้นใหม่อีกครั้ง คราวนี้ พยบ. จัดท่าอุ้มลูกฟุตบอลให้แม่ปุ๊ลองให้นม พอปากถึงเต้านมอัลตร้างับดูดทันที แม่ปุ๊ร้องไห้อีกครั้ง เพราะรอบนี้ได้คะแนน 10/10 🎉 ส่วนพ่อก็รับหน้าที่อุ้มเรอไป

คุณป้าหมอมาเยี่ยม พร้อมตรวจเต้านม คุณป้าหมอบอกมีน้ำนมแล้วดีมาก แถมอัลตร้าร้องลั่นอยากโชว์ ป้าหมอไม่รอช้าอุ้มจับเข้าเต้าทันทีในท่ามาตราฐาน เรียบร้อย perfect!!! พร้อมคำชมมากมายจากป้าหมอ พร้อมฉายา “จิ๋วของป้าหมอ”

วันนี้ทั้งวันเข้าเต้ามาตลอดจนถึงมื้อค่ำ จิ๋วเริ่มไม่ไหวร้องลั่นจนต้องเสริมนมผงไป 2 รอบ นอนสบายเลย จนเที่ยงคืนครึ่ง ตื่นมาเข้าเต้่ารอบนี้รู้สึกอัลตร้าตัวร้อนๆ เลยโทรตาม พยบ. มาวัดไข้ ถึงจะปกติแต่แม่ปุ๊กลัวไม่สบายเลยฝากพี่พยบ. ช่วยดูแลอีกคืน

วันนี้อยู่ด้วยกันถึงตี 1 อยู่กับพี่พยบ. พี่ๆ บอกก็กินเก่งขึ้น และน้องไม่กวนเลย

อัลตร้าน้อยผู้หิวโหย

วันที่ 3 เข้าเต้าครั้งนี้ พ่อไม่ต้องช่วยอัลตร้าเล็งแล้ว หนูหิวหนูหาเองได้พ่อ แต่ก็ยังลำบากทุกครั้งที่เข้าเต้าเนื่องจากแม่ปุ๊ยังจับจังหวะไม่ได้ พอเข้าถูกจังวะปุ๊บอัลตร้าก็ดูดยาวๆ เลย

แต่น้ำนมแม่คงยังมาไม่เยอะพอที่จะทำให้อัลตร้าอิ่มจนหลับได้ยาวๆ ตั้งแต่บ่าย 2 จนถึง 1 ทุ่ม อัลตร้าไม่เคยนอนเกิน 40 นาที เลย ร้องกินนมตลอด จนแม่ต้องโทรขอ พยบ. มาช่วยดูให้ ซึ่งแน่นอนอัลตร้าไม่อิ่ม เลยต้องเสริมนมผงไปบ้าง

คืนที่ท้าทาย

คืนนี้คืนสุดท้ายก่อนกลับบ้าน พยบ. พาไปสอนอาบน้ำ และเมื่อกลับมาถึงห้อง พยบ. ก็ให้พ่อถามคำถามมากมาย และทิ้งท้ายว่าคืนนี้อยากให้แม่ให้นมแม่เองทั้งคืน ให้คิดว่าไม่มีนมผงในโลก แม่ลองสู้หน่อยสักคืน หิวปุ๊บเข้าเต้าปั๊บ ถี่หน่อยนะคืนนี้ เพื่อคืนต่อๆ ไปจะได้สบาย (แต่ถ้าไม่ไหวโทรตามได้ตลอดเวลา) ไม่รู้จะเป็นยังไงบ้างคืนนี้ ตอนนี้ได้ให้แม่ปุ๊นอนพักไปแล้ว

สู้ๆ นะแม่ปุ๊ พ่อจะค่อยนอน(รออุ้มเรอ)อยู่ข้างๆ 😜

ไม่ไหวอย่าฝืน

คุณแม่สำคัญที่สุด ถ้าเครียดไปก็ส่งผลต่อน้ำนม ฝืนให้นมจนไม่ได้พักผ่อน ไม่สบายขึ้นมาลูกจะกินอะไร คุณป้าหมอ คุณพี่พยบ. ก็ส่งเสริมให้กินนมจากเต้าทุกคน แต่ถ้าคุณแม่ไหวแล้ว จะเสริมนมผงบ้่างก็ไม่ได้ผิดอะไร เอาที่พอดี ทุกอย่างจะดีเอง

เจ้าหนูอัลตร้า was originally published in ultra-journey on Medium, where people are continuing the conversation by highlighting and responding to this story.

#1 พบกันครั้งแรก

วันนี้คุณหมอนัดให้มาผ่าคลอด โดยให้มาเตรียมตัวตั้งแต่ตี 4:30 น. คุณแม่ก็ไปวัด v/s ส่วนพ่อไปจ่ายเงินมัดจำ เป็นไปตามที่แม่คิดไว้บัตรเครดิตรูดไม่ได้ บอกกำลังปรับปรุงข้อมูลอยู่ ไปกดเงินสด กดอยู่หลายรอบกว่าจะได้บอกการสื่อการผิดพลาด อัลตร้าเกือบไม่ได้คลอดซะแล้ว

หลังจากจ่ายมัดจำเรียบร้อย ก็เข้ามานอนเตรียมตัวในห้องพัก วัดไข้ เจาะเลือด ตรวจน้ำตาล สรุปน้ำตาลต่ำ โดนน้ำเกลือไป 2 เท่า + น้ำตาลไปอีกขวด

ถึงเวลานัด พยาบาลมารับแม่ไปห้องผ่าตัด ส่วนพ่อต้องยืนรอพยาบาลเด็กพาไปเปลี่ยนชุดตามไปทีหลัง รออยู่นานมากจนนึกว่าเค้าลืมไปซะแล้ว พอเปลี่ยนเสื้อผ้าเสร็จก็ย้ายไปนั่งรอหน้าห้องผ่าตัด ดูเวลาครั้งสุดท้าย 9:40 น. สักพักพยาบาลก็เดินมาตาม

เข้าห้องผ่าตัด เห็นหมอน่าจะเริ่มผ่าไปแล้ว พยาบาลรีบตามให้มานั่งด้านบนหัวปุ๊ เก้าอี้สูงเกินฉากกั้น พยาบาลรีบมาเอาตัวใหม่เปลี่ยน นั่งลูบหัวปุ๊ แต่ปุ๊ดันไม่รู้ว่าใคร ฮาๆ คนกำลังมึน เห็นปุ๊บีบตา 2–3 ครั้ง น่าจะเจ็บ อยู่ๆ หมอก็สะดุ้ง ก่อนเสียงหัวเราะก็ตามมา ปุ๊ตกใจมาก นึกว่าอัลตร้าเป็นอะไร ที่แท้อัลตร้าเกือบเตะเข้าหน้าหมอ หมอบอกอย่ารีบลูก แปปเดียวออกมาทั้งตัว ประกาศเวลาคลอด 9:53 น. เสียงร้องลั่นห้องผ่าตัด ปุ๊ค่อยถามตลอดว่าลูกโอเคมั้ย ทั้งหมอทั้งพยาบาลบอกร้องขนาดนี้แข็งแรงแน่นอน พยาบาลก็มาขอโทรศัพท์จะถ่ายรูปให้ แต่พ่อนึกว่าเอาเข้าไม่ได้ ก็เลยใช้เครื่องของพยาบาลห้องเด็กแทน

หลังทำความสะอาด ชั่งน.น. ตรวจเสร็จ คุณหมอเด็กก็ย้ายอัลตร้าไปอีกห้อง พ่อก็ต้องออกไปพร้อมกัน พยาบาลจับตัวพาเดินออกไป โดยไม่ยอมให้หันไปดูบนเตียง สงสัยกลัวพ่อจะเป็นลม 😅 เปลี่ยนชุดเสร็จรีบวิ่งไปหยิบโทรศัพท์ แล้วตามไปห้องเด็กอ่อนทันที

รอคุณหมอเด็กตรวจเสร็จ พยาบาลให้เปลี่ยนชุดอีกรอบ คุณหมอก็อธิบายหลายๆ อย่าง สรุป ok แต่น.น. เฉียดไปนิดเดียว บวกกับมีประวัติตัวเล็กในครรภ์ เลยขอติดตามอาการอีก 24 ช.ม.

เหมือนต้องมนต์สะกด… ยืนดูอัลตร้านอนอยู่ในตู้ปรับอุณหภูมิ เวลาผ่านไปเร็วมาก 1 ช.ม. จนพยาบาลต้องบอกให้ไปพักก่อน เพราะคุณแม่ใกล้จะออกจากห้องพักฟื้นแล้ว เดี๋ยวอาบน้ำ ฉีดวัคซีนเสร็จจะพาอัลตร้ามาเข้าเต้า

กลับมานั่งรอในห้องไปแปปเดียวปุ๊ก็เข้ามา พุงหายไปเยอะเลย พ่ออยากพุงหายบ้าง😭 รออยู่เกือบ 2 ช.ม. อัลตร้าก็มาหาแม่แล้ว 🥰

ลองเข้าเต้ากันอยู่นาน แต่อัลตร้าไม่ยอมตื่น งับทีสองที ก็นอนต่อ จนต้องปล่อยให้นอนต่อไป รอให้หิวแล้วตื่นเอง (ต้องขอบคุณพยาบาล ก้มๆ เงยๆ ช่วยกันอยู่นานหลายสิบนาที)

สุดท้ายก็หลับไปทั้งแม่ และลูก หลับกันแบบนี้คืนนี้ยาวแน่นอน 😱

ปล. หล่อได้พ่อจริงๆ

เจ้าหนูอัลตร้า was originally published in ultra-journey on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. ใช้ babel
2. ใช้โมดูล esm

แบบใช้ Babel

• เริ่มจากสร้างโปรเจค mkdir node-es6-babel && cd $_
• สร้างไฟล์ package.json npm init -y
• ติดตั้ง babel npm i -D @babel/cli @babel/core @babel/node @babel/preset-env
• สร้างไฟล์ .babelrc (touch .babelrc) แล้วตั้งค่าตามนี้

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": {
          "node": "current"
        }
      }
    ]
  ]
}

"node": "current" คือ ระบุ version ของ nodejs ที่ใช้รัน babel อยู่ (เหมือน "node": process.versions.node)

• สร้างไฟล์ src/index.js และไฟล์ src/my-module.js

// src/my-module.js
// Named export - Has a name. Have as many as needed.
export const message = 'Some message from my-module.js';

// Default export - Has no name. You can only have one.
export default (name) => `Hello ${name}`;

// or
// const message = 'Some message from my-module.js';
// const getGreeting = (name) => `Hello ${name}`;
// export { message, getGreeting as default }

// src/index.js
import greetingFn, { message } from './my-module';

console.log(message);

console.log(greetingFn('Ball'));

• แก้ไข script ในไฟล์ package.json ตามนี้

{
  "scripts": {
    "start": "babel-node src/index.js"
  },
}

หรือถ้าใช้ร่วมกับ nodemon

{
  "scripts": {
    "start": "nodemon src/index.js --exec babel-node -e js"
  },
}

• ทดสอบรันดู npm run start

Some message from my-module.js
Hello Ball

• เมื่อจะเอาโค้ดไป deploy ต้อง build ก่อน ทำได้โดยเพิ่ม scripts ใน package.json ดังนี้

{
  "scripts": {
    "start": "babel-node src/index.js",
    "clean": "rm -rf dist",
    "build": "npm run clean && mkdir dist && babel src -s -d dist --copy-files",
    "prod": "export NODE_ENV=production||set NODE_ENV=production&&node dist/index.js",
  },
}

• build โดยคำสั่ง npm run build จะได้ folder dist ออกมา
• รันโดยใช้คำสั่ง npm run prod

แบบใช้ NPM module ESM

• เริ่มจากสร้างโปรเจค mkdir node-es6-esm && cd $_
• สร้างไฟล์ package.json npm init -y
• ติดตั้ง esm npm i esm
• สร้างไฟล์ src/index.js, src/main.js และไฟล์ src/my-module.js

// src/my-module.js
// Named export - Has a name. Have as many as needed.
export const message = 'Some message from my-module.js';

// Default export - Has no name. You can only have one.
export default (name) => `Hello ${name}`;

// or
// const message = 'Some message from my-module.js';
// const getGreeting = (name) => `Hello ${name}`;
// export { message, getGreeting as default }

// src/main.js
import greetingFn, { message } from './my-module';

console.log(message);

console.log(greetingFn('Ball'));

// src/index.js
require = require('esm')(module);
module.exports = require('./main.js');

• แก้ไข script ในไฟล์ package.json ตามนี้

{
  "scripts": {
    "start": "node ./src/index.js",
    "dev": "nodemon ./src/index.js",
    "prod": "export NODE_ENV=production||set NODE_ENV=production&&npm start"
  },
}

หรือถ้าใช้ร่วมกับ nodemon

{
  "scripts": {
    "start": "node ./src/index.js",
    "dev": "nodemon ./src/index.js",
    "prod": "export NODE_ENV=production||set NODE_ENV=production&&npm start"
  },
}

• ทดสอบรันดู npm run start หรือ npm run dev

Some message from my-module.js
Hello Ball

• เมื่อจะเอาโค้ดไป deploy แบบนี้ไม่ต้อง build สามารถรันได้เลยโดยใช้คำสั่ง npm run prod

สามารถดูตัวอย่างโค้ดทั้งหมดได้ใน github

select * from tasks where due_date = $P{date}

-- or

select * from tasks where due_date between $P{start_date} and $P{end_date}

แต่ถ้าต้องการเพิ่มเงื่อนไขว่าถ้า $P{date} มีค่าเท่ากับ null ให้แสดงค่าทั้งหมดออกมา เราจะไม่สามารถใช้ $P{date} is null ได้เหมือนกับพารามิเตอร์แบบ String

select * from tasks where $P{date} is null or due_date = $P{date}

Error filling print... Error executing SQL statement for : sample-report
net.sf.jasperreports.engine.JRException: Error executing SQL statement for : sample-report

หมายเหตุ ถ้า $P{date} มีค่าเป็น null จะสามารถทำงานได้ แต่ถ้ามีค่าจะไม่สามารถทำงานได้

วิธีการที่ถูกต้อง คือ ต้องใส่ $X{} expression มาช่วยในการตรวจสอบค่า null ดังนี้

select * from tasks where $X{EQUAL, NULL, date} or due_date = $P{date}

นอกจากนี้ยังสามารถใช้ $X{} expression กับ Date ได้อีก ดังนี้

• $X{LESS, column, date} คือ column value < $P{date}
• $X{LESS], column, date} คือ column value<= $P{date}
• $X{GREATER, column, date} คือ column value> $P{date}
• $X{[GREATER, column, date} คือ column value>= $P{date}
• $X{BETWEEN, column, start_date, end_date} คือ column value >= $P{start_date} AND column value <= $P{end_date}

หมายเหตุ ส่วนตัวลอง $X{BETWEEN, column, start_date, end_date} แล้วไม่ได้ผล เพราะมันดันเอาเวลาไปใช้ด้วย

ตัวอย่าง

ถ้าต้องสร้างรายงานแสดงรายการงาน พร้อมแสดงวันที่ส่งงาน โดยสามารถค้นหาได้จากช่วงวันที่ หรือแสดงทั้งหมดเมื่อวันที่เป็น null ตามนี้

Step 1: เตรียมฐานข้อมูล

ในตัวอย่างนี้ ผมได้เตรียมข้อมูลเอาไว้แล้วเป็น PostgreSQL ซึ่งสามารถรันได้จาก Docker ตามนี้

docker container run --rm -p 5433:5432 somprasongd/pg10-sample-db

แต่ถ้าต้องการสร้างตารางเองก็สามารถใช้คำสั่งด้านล่างนี้ได้

CREATE TABLE public.tasks (

id serial NOT NULL,

name varchar(100) NOT NULL,

due_date date NOT NULL,

created_at timestamptz NOT NULL DEFAULT now(),

CONSTRAINT tasks_pk PRIMARY KEY (id)

);

CREATE INDEX tasks_due_date_idx ON tasks USING btree (due_date);

INSERT INTO public.tasks (name, due_date) VALUES

('Task #1', now())

, ('Task #2', now() + interval '2 day')

, ('Task #3', now() + interval '4 day')

, ('Task #4', now() + interval '6 day')

, ('Task #5', now() + interval '8 day')

, ('Task #6', now() + interval '10 day')

, ('Task #7', now() + interval '20 day')

, ('Task #8', now() + interval '22 day')

, ('Task #9', now() + interval '30 day')

, ('Task #10', now() + interval '60 day');

-- ข้อมูลจะเริ่มจากวันที่ที่นำข้อมูลเข้าครั้งแรก เช่น วันนี้วันที่ 11 Oct 2018 Task #1 จะมี due_date เป็นวันที่ 11 Oct 2018

Step 2: เชื่อมต่อฐานข้อมูลกับโปรแกรม iReport

เนื่องจากผมใช้ฐานข้อมูลจาก docker โดยกำหนด

• port: 5433
• database name: sample-db
• username & password: postgres

Step 3: สร้างไฟล์ sample-report.jrxml

เมื่อสร้างไฟล์ใหม่จะได้ออกมาแบบนี้

เริ่มจากสร้าง parameter 2 ตัว คือ
- $P{start_date} เป็น java.util.Date ค่าเริ่มต้นเป็น null
- $P{end_date} เป็น java.util.Date ค่าเริ่มต้นเป็น null

เสร็จแล้วเขียน SQL ตามนี้

SELECT name, due_date
FROM tasks
WHERE ($X{EQUAL, NULL, start_date} or $X{EQUAL, NULL, end_date} or
due_date between $P{start_date} and $P{end_date})
ORDER BY due_date

จัดหน้าจอตามตัวอย่าง

หรือถ้าขี้เกียจ ให้เลือกที่ XML แล้ว copy โค้ดด้านล่างนี้ไปวางทับทั้งหมด

Final Step: ทดสอบ Preview

กดที่ปุ่ม Preview จะมีหน้าต่าง Parameter prompt ขึ้นมาให้เลือกวันที่ start_date และ end_date

ถ้าเลือก start_date และ end_date เป็น Use default

รายงานก็จะแสดงข้อมูลทั้งหมดออกมาแทน

ซึ่งเมื่อพัฒนาโปรแกรมเสร็จ และเราต้องการจะสร้างตัวติดตั้ง Netbeans ก็ได้เตรียม build script ไว้ให้แล้ว แต่ติดปัญหาอยู่ 2 ข้อคือ การกำหนดค่า Java heap size เริ่มต้นที่ 24Mb และสูงสุดที่ 64Mb อาจทำให้เกิดปัญหา Out of Memory ได้ กับ icon ของโปรแกรมจะได้เป็น icon Java สีดำๆ ออกมาเสมอ โดยเราสามารถแก้ไขปัญหาทั้ง 2 ข้อนี้ ด้วยไปแก้ไขไฟล์ Build Script ของ Netbeans

การกำหนดค่า Java heap size

• เปิดไฟล์ suite.xml ถ้าเป็น Windows จะอยู่ที่ C:\Program Files\NetBeans 8.2\harness\suite.xml
• เลื่อนไปหา target ที่ชื่อว่า “build-launchers”
• แทรกข้อความ <replace file="${app.conf}" token="-J-Xms24m -J-Xmx64m" value="-J-Xms256m -J-Xmx512m" /> โดยที่ value คือค่าที่เราต้องการไปแทนที่ค่าเดิม ตำแหน่งที่ต้องแทรกโค้ดดูตามรูปด้านล่าง

แต่วิธีข้างต้นจะเป็นการแก้ไขที่ส่งผลต่อทุกโปรเจค ถ้าหากต้องการแก้ไขให้แต่ละโปรเจคมีการกำหนดค่า Java heap size แตกต่างกัน สามารถทำได้ ดังนี้

• เปิดไฟล์ project.properties โดยเลือกที่ชื่อโปรเจค > Important Files > Project Properties
• เพิ่ม run.args.extra=-J-Mmx256m -J-Xmx512m แล้วบันทึก

• เปิดไฟล์ suite.xml ถ้าเป็น Windows จะอยู่ที่ C:\Program Files\NetBeans 8.2\harness\suite.xml
• เลื่อนไปหา target ที่ชื่อว่า “build-launchers”
• แทรกข้อความ <replace file="${app.conf}" token="-J-Xms24m -J-Xmx64m" value="${run.args.extra}" /> ซึ่งในขั้นตอนการ build โปรแกรมจะสามารถเข้าถึงค่าที่กำหนดไว้ใน project.properties ได้โดยใช้ ${ชื่อ}

วิธีนี้นอกจากจะกำหนดแยกรายโปรเจคได้แล้ว ทุกครั้งที่สั่ง Run โปรแกรมเพื่อทดสอบ Netbeans จะใช้ค่า Java heap size ตามที่กำหนดไว้ใน run.args.extra ด้วย

การเปลี่ยน Executable Icon บน Windows

ขั้นตอนปกติในการสร้าง app.exe นั้น Netbeans จะทำการ copy ไฟล์ C:\Program Files\NetBeans 8.2\harness\launchers\app.exe มาไว้ที่ [yourproject]\build\launcher\bin\

จากนั้นจะเปลี่ยนชื่อโดยใช้ชื่อจาก app.name ที่กำหนดไว้ใน project.properties แต่ไม่ทำการเปลี่ยน icon ให้ ดังนั้นเราจะต้องใช้ third-party utility program มาช่วยในการเปลี่ยน icon แทน เช่นใช้โปรแกรม ReplaceVistaIcon.exe รันผ่าน command line

วิธีการแก้ไขไฟล์ Build Script เพิ่มเรียกใช้ ReplaceVistaIcon.exe ทำได้ดังนี้

• เปิดไฟล์ suite.xml ถ้าเป็น Windows จะอยู่ที่ C:\Program Files\NetBeans 8.2\harness\suite.xml
• เพิ่มโค้ดด้านล่างไว้ใน <project>...</project>

อธิบายโค้ด
condition เอาไว้ตรวจสอบว่าใช้ OS Windows หรือไม่
replaceWindowsLauncherIcon เป็น target ใหม่ที่สร้าง เพื่อจะเรียกใช้ในขั้นตอนการสร้างไฟล์ app.exe โดยตัวมันเองจะไปเรียกใช้ ReplaceVistaIcon.exe เพื่อเปลี่ยน icon ของ app.exe ซึ่งโดยปกติจะมีไฟล์ .exe อยู่ 3 ตัวคือ app.exe, app64.exe และ app_w.exe

• เรียกใช้ target="replaceWindowsLauncherIcon" ใน target="build-lanchers"แทรกโค้ด <!--Replace the icon for the Windows launcher exe.--><antcall target="replaceWindowsLauncherIcon"/> หลังการ copy และ rename app.exe เสร็จแล้ว ดังนี้

เมื่อแก้ไขเสร็จทั้งหมดแล้วลองสร้างตัวติดตั้งดู

ก็จะได้โปรแกรมที่มี icon และการกำหนดค่า Java heap size ตามที่เรากำหนดไว้แล้ว