DEV Community: Long Nguyễn Xuân

Thiết lập hệ thống quản lý task bằng jira

Long Nguyễn Xuân — Wed, 07 Jan 2026 15:39:14 +0000

vì sao?

làm dự án phần mềm nhiều người thì không thể tách rời các công cụ quản lý,
jira là No. 1 về software project management tool trên toàn thế giới
trong quá trình làm đồ án SEP490, thì áp dụng jira giúp chúng ta làm quen với công cụ quản lý dự án phần mềm #1 này, sau ra đời bớt bỡ ngỡ
dùng excel cũng tốt, nhưng hội đồng phản biện đánh giá cao jira

cách làm ngắn gọn

vào https://www.atlassian.com/software đăng ký 1 tài khoản
tạo 1 dự án, đặt tên, mời bạn bè
tạo task phù hợp với các việc cần làm trong dự án
update trạng thái task định kỳ
chụp ảnh đem nộp trong báo cáo

tiêu chí chấp nhận

nhìn vào jira thấy được "mỗi người từ ngày 2026-01-07 tới ngày 2026-01-15 làm việc gì, estimate bao nhiêu effort, sum effort ~40h"

mapping cấu trúc default của jira với cấu trúc công việc đồ án

epic: 
  "ý nghĩa": "feature, hoặc mục tiêu lớn cần giải quyết" 
  user_story: 
    "ý nghĩa": "== function, 1 user_story có nhiều con là sub_task" 
    sub_tasks: 
      - "viết spec (report 3 - functional detail)" 
      - "viết class diagram & sequence diagram (report 4)" 
      - "code (BE & FE)" 
      - "viết unit test case (report 5-unit test) - cái này thường do BE Dev làm" 
      - "viết system test case (report 5_test report) - người này khác người code" 
      - "run test - chỉ closed khi tất cả bug được fix"
  bug: "lỗi bắt được, có link với user_story để xác định dính với function nào" 
  task: 
    "ý nghĩa": > 
      "công việc nhỏ lẻ, không trực thuộc user_story, 
      ví dụ: set up môi trường, deploy, họp hành..."

chi tiết thao tác

vào https://www.atlassian.com/software và mày mò đi

estimate

trả lời cho câu hỏi "task này dự kiến mất bao nhiêu giờ"

original estimate và remain estimate (trong time tracking) nó không được hiển thị ra ngay từ đầu,
phải chọn 1 issue type, sau đó chọn config, rồi add thêm

lúc này cái field original estimate sẽ hiện ra

lúc này ta có thể update field này, để "estimate" cho công việc ta cần làm

có thể estimate mức user story, hoặc mức sub-task, tùy theo độ "mịn" mà mong muốn quản lý task

calendar

sau estimate là calendar, trả lời cho câu hỏi "task này dự kiến làm từ ngày nào tới ngày nào"

kéo và thả các task từ bên cột task vào trong cái ngày tháng tương ứng

Test Environment

Long Nguyễn Xuân — Mon, 15 Dec 2025 16:29:36 +0000

khi làm đồ án, ở file Report 5_Test Documentation.docx và sau này đi làm các bạn sẽ tiếp xúc với khái niệm "Test Environment" và sau này là những cái environment khác như

Dev Environment: nơi dev tạo ra tính năng mới và fix bug, thường chung với Unit Test Environment
Test Environment: nơi tester kiểm tra chức năng, tùy độ phức tạp dự án mà có thể chia Integration Test Env và System Test Env.
UAT Environment: nơi khách hàng nghiệm thu sản phẩm.
Staging Environment (đôi khi bị trộn lẫn với UAT, nhưng bản chất khác): đây là nơi tái hiện môi trường production, giống nhất có thể, thường được dựng lên tạm thời để test load, hoặc thử nghiệm các kịch bản triển khai
Production Environment: nơi end user thực sự dùng sản phẩm, nơi tiền thực sự được sinh ra.

Tối thiểu nhất, ở mức đồ án, các bạn bị yêu cầu viết "Test Environment", thì nó có tối thiểu 2 thứ

Unit Test Environment
System Test Environment

trong 2 cái này, các bạn liệt kê các thông tin "tool" thực tế là hạ tầng cần thiết để "chạy unit test được" và "chạy system test được"

ví dụ như hình dưới

cái "environment" này nó là 1 "khái niệm Logic"
đôi khi nhiều env có thể được cài đặt chung trên 1 server,

lấy ví dụ như 1 cái app React, .NET, MySQL, S3
thì trên 1 con Ec2 hoặc VPS nào đó, có thể chạy đồng thời cả Dev Env và Test Env
chỉ cần config để mỗi cụm FE+BE chạy trên 1 port khác nhau là OK
ngay trên con server này cũng cài luôn cả database server, và tạo 2 cái schema,
ngay trên con server này cài seaweedFS giả lập S3 rồi map 2 bucket vào là OK.

Các điểm cần lưu ý về Business Rule

Long Nguyễn Xuân — Sun, 14 Dec 2025 17:48:51 +0000

Định nghĩa

Business Rule là "Quy tắc nghiệp vụ" nó là những "quy định, quy tắc, luật" mà cái ứng dụng của chúng ta phải tuân thủ.

ví dụ

luật việt nam quy định người "đủ 18 tuổi" thì được mua rượu. (!!)
ở Mỹ, đủ 21 tuổi (!!) mới được mua rượu.
vậy thì cái "18 tuổi" và "21 tuổi" đó là "business rule"

(!): thực tế ở vn mấy tuổi đi mua rượu không phải nội dung bàn luận của blog này :)
(!!): luật Mỹ nó phức tạp, và cũng không phải trọng tâm của blog này :)

trọng tâm là,

nếu bạn làm 1 cái app mua bán hàng, và có bán rượu, thì cái app đó phải có chức năng cho phép người ta khai báo tuổi, và nếu người mua đang <18 (vn) hoặc <21 (us) thì không cho thực hiện hành động mua rượu từ website của bạn,
nếu bạn không có tính năng này, ứng dụng của bạn nó đang vi phạm pháp luật, và có thể bị "gõ" nếu bị cơ quan có thẩm quyền kiểm tra (audit)

ngoài cái này, có nhiều "business rule" khác, tùy thuộc vào ngữ cảnh của ứng dụng bạn đang làm, nó có thể là quy định công ty, có thể là đặc trưng văn hóa của cộng đồng v.v.

#	Business Rule (Quy tắc nghiệp vụ)	Functional Requirement (Yêu cầu chức năng)
Bản chất	Chính sách của công ty/pháp luật.	Tính năng của phần mềm.
Ví dụ	"Chỉ người dùng trên 18 tuổi mới được mua rượu."	"Hệ thống phải hiển thị popup yêu cầu nhập ngày sinh. Nếu nhập < 18 tuổi, nút 'Mua hàng' sẽ bị vô hiệu hóa."
Sự thay đổi	Thay đổi khi chính sách kinh doanh thay đổi.	Thay đổi khi Business Rule đổi hoặc khi công nghệ/UI đổi.
Phạm vi	Áp dụng cho toàn doanh nghiệp.	Áp dụng cho một màn hình hoặc một tính năng cụ thể.

Các ví dụ khác về business rule

quy tắc về định nghĩa: khách hàng vip là khách hàng có tổng chi tiêu >100M / năm
quy tắc ràng buộc ví dụ: mật khẩu phải có độ dài tối thiểu 16 ký tự và bao gồm chữ hoa, chữ thường, số, ký tự đặc biệt, không trùng với 5 mật khẩu gần nhất v.v.
quy tắc tính toán ví dụ: thuế VAT 8%
ràng buộc sự kiện: nếu khách hàng trễ thanh toán 30 ngày thì hệ thống tự động khóa tài khoản.

Trình bày đồ án như thế nào?

Long Nguyễn Xuân — Mon, 08 Dec 2025 15:15:03 +0000

Ngắn gọn

trình bày đủ (điểm 7) - chi tiết xem FLM và file rubric
có điểm nhấn để gây ấn tượng (điểm 8-9-10)

chi tiết

trước khi vào "how" ta quay lại một chút về "why"

Vì sao phải trình bày đồ án?

ở mức cơ bản nhất: phát hiện gian lận. nhóm sinh viên có thực sự là người làm ra sản phẩm này không? hay đi cóp ở đâu về, hay tệ hơn, thuê người làm hộ? cái này thì không có gì để bàn.
đánh giá năng lực diễn đạt: communication bạn có thể làm rất tốt, nhưng nếu không thể trình bày được sản phẩm của mình, vậy cần luyện trình bày cho đạt chuẩn thì mới có khả năng tham gia vào thị trường lao động, đừng có lý luận rằng "tôi chỉ biết làm, tôi không cần nói", không ai đòi hỏi bạn vừa phải code như 1 kỹ sư, vừa phải "nói như hát" ở tầm saleman, nhưng "nếu không thể trình bày" vậy thì có nghĩa là năng lực của bạn chưa đạt chuẩn, chưa đạt thì học lại cho đạt.
đánh giá tư duy: phản biện và bảo vệ quan điểm. bạn có đủ kiến thức, và tư duy để bảo vệ lập trường của mình không? hay ai nói gì cũng gật? nếu không đủ kiến thức, không đủ tư duy, vậy ở lại học thêm cho đủ rồi ra đi làm
góc nhìn đa chiều: tất cả developer, hay người làm kỹ thuật nói chung thường mắc phải nhược điểm lớn "sản phẩm của tôi là tuyệt vời", những nhận xét, góp ý của hội đồng phản biện, bao gồm các giảng viên (học thuật) và đại diện doanh nghiệp (thực tế) sẽ giúp các bạn mở rộng tầm suy nghĩ, nhận ra những lỗ hổng mà sinh viên chưa nghĩ tới (khả thi kinh tế, bảo mật, trải nghiệm người dùng v.v.)
cuối cùng: lễ trưởng thành trước buổi bảo vệ, bạn là "người học", sau buổi bảo vệ, bạn là đồng nghiệp với các kỹ sư (doanh nghiệp) và thầy cô của mình.

Vậy trình bày cái gì và như thế nào?

Nguyên tắc

không cần show hết, chỉ cần show những cái hay nhất
đồ án đó 5 sinh viên làm trong 3 tháng, nếu không thể trình bày trong 45p, vậy bạn trình bày chưa đạt.

OK, chốt lại cái dàn bài nó thế này

Intro (lựa chọn đề tài) : có lý do rõ ràng, có số liệu hỗ trợ, trình bày được 5 yếu tố
1. context (fact)
2. nỗi đau / cơ hội
3. nhu cầu / hệ thống đã có + ưu nhược
4. giải pháp
5. lợi ích dự kiến
Project management
1. mô hình & cách áp dụng mô hình vào trong dự án
2. vai trò trách nhiệm
3. cách quản lý code / docs trong dự án
4. ... other ..
Requirement
1. business workflow
2. use case diagram
3. ERD (optional)
4. Screen flow ( optional )
5. non functional requirement (optional)
Architect
1. overview technical
2. package diagram (MVC / 3 layers / microservices / clean architect / Dependency Injection / Domain Driven Design)
3. Database
4. deployment architect (optional)
Testing
1. Test plan: functional / nonfunctional unit + system + ?? công cụ / công nghệ test đơn giản: chrome + excel phức tạp: selenium + jmeter + junit + ...
2. quy trình quản lý bug
3. Test Result số lượng test case, phân bổ NAB số lượng bug
demo (20-25p)
nguyên tắc: bám theo business workflow, kể 1 câu chuyện vv user dùng hệ thống thì đạt được lợi ích gì?
1. negative cases không cần làm
2. những cái đơn giản quá: đăng ký / forgot password / view own profile : không cần
3. chuẩn bị demo data : file word text, folder images, không nhập những thứ vô nghĩa như "asdf" hay "testtest"
conclusion
1. mở bài (intro) hứa làm cái gì, đã làm được chưa?
2. tự nhận xét còn thiếu sót gì? kế hoạch tương lai để cải tiến ra sao?
3. học được gì qua dự án này

Vẽ quy trình nghiệp vụ bằng BPMN trong DrawIO

Long Nguyễn Xuân — Tue, 09 Sep 2025 14:25:54 +0000

Vẽ quy trình nghiệp vụ bằng BPMN trong DrawIO

TLDR

ở panel bên trái cửa sổ DrawIO, bấm "More shapes..."
trong pop up mới hiện ra, ở panel bên trái, kéo xuống phần business, có BPMN 2.0, tick vào ✅ nhấn Apply
Enjoy

hình ảnh

xem hình ảnh

context

khi làm đồ án SEP490, từ kỳ SP25, có yêu cầu tăng cường phần "business workflow" để trình bày được cái luồng nghiệp vụ tổng quan của hệ thống, tránh trình bày lan man,

để vẽ cái business workflow này, có nhiều cách, tự sáng tạo cú pháp cũng OK, nhưng có 1 môn "võ công" chuyên cho việc này, gọi là BPMN - Business Process Model Notation. võ công này thường là "tuyệt kỹ trấn phái" của nghề "BA - Business Analyst" nhưng mà [1] ở level sinh viên [2] thời GenAI lên ngôi, ranh giới các vị trí trong ngày nó sẽ rất mờ nhạt, cho nên học đi, không thiệt đâu.

làm với thầy Long thì phải dùng BPMN.

BPMN Hello world

tình huống thực tế

cân nhắc tình huống *đi mua trà sữa ở quán *hiện đại ** và vẽ BPMN cho nó

start
khách vào quán
khách chọn món, yêu cầu tùy chỉnh (nếu có) như thêm kem cheese, thêm trân châu v.v.
thu ngân lên đơn, bill hiển thị trên màn hình
user thanh toán.
user cầm cục tín hiệu ra bàn ngồi chờ
thu ngân in "phiếu nước" để barista thực hiện pha chế.
barista nhìn phiếu, pha nước, đặt vào quầy "hoàn thành", nhấn nút hoàn thành trên hệ thống.
cục tín hiệu rung,
khách cầm cục tín hiệu tới quầy hoàn thành, trả cục tín hiệu, cầm nước ra bàn.
end

lý thuyết

các thành phần chính trong BPMN gồm

Swimlanes (pool & lane)

Pool: đại diện cho thực thể lớn như tổ chức, doanh nghiệp, hoặc một nhóm những người cùng tham gia vào 1 hoạt động (quy trình) nào đó.
Lane: các cá nhân, hệ thống tự động tham gia vào quy trình.

Flow Elements

**Event (sự kiện): **là điểm bắt đầu, kết thúc hoặc các sự kiên trung gian trong quy trình, biểu diễn bằng 1 hình tròn nhỏ
Activity (hoạt động): là các hành động của người, hoặc hệ thống tự động (ví dụ: bank system) trong quy trình.
Gateway (Cổng): Dùng để quyết định hoặc điều khiển luồng, biểu diễn bằng hình thoi. Đây là nơi tách hoặc hợp luồng trong quy trình

Connecting Objects (Kết nối giữa các thành phần):

Sequence Flow: Mũi tên nối các hoạt động theo trình tự thực hiện, được vẽ bằng nét liền.

Message Flow: Dùng để thể hiện luồng thông tin hoặc tin nhắn giữa các pool hoặc lane, vẽ bằng nét đứt.

Associations: Liên kết giữa các đối tượng dữ liệu và hoạt động.

Artifacts (Hiện vật hỗ trợ):

Data Objects: Thể hiện dữ liệu được sử dụng hoặc tạo ra trong quy trình.
Groups: Nhóm các hoạt động liên quan lại với nhau để trực quan hóa.
Annotations: Chú thích thêm thông tin cho biểu đồ để người xem dễ hiểu hơn.

áp dụng lý thuyết ta có sản phẩm như sau

chú ý rằng ta có 2 "lane" không được mô tả trong hệ thống ban đầu, là cái Payment system và coffeshop management system
thì đây là 2 hệ thống mà mình phải "tích hợp" hoặc "xây dựng"

https://1drv.ms/u/c/c75562f009b87df4/Ed98YxdDqrFNjyB6zq5yOQsBgFRB1wv_Ig5jRCtTe28U6A?e=8ObqGV

Config git user.name để kiểm soát code

Long Nguyễn Xuân — Fri, 29 Aug 2025 14:40:54 +0000

ngắn gọn

các nhóm sinh viên làm code với thầy Long thì thực hiện thao tác dưới:

mở Terminal trong folder code của dự án
gõ lệnh sau git config --global user.name "Ten Day Du Tieng Viet Khong Dau"

ví dụ: git config --global user.name "Nguyen Xuan Long"

kết quả

trước khi gõ lệnh: nhấn vào xem ảnh

sau khi gõ lệnh: nhấn vào xem ảnh

giải thích chi tiết

Git cho phép ta config lại các biến môi trường theo 3 tầng

Local: chứa trong cái local repo, là cái .git folder code đang làm việc.
global: là các config áp dụng với tất cả repo, chứa trong ~/.gitconfig hoặc C:\Users\<user>\.gitconfig
system: là config áp dụng với tất cả user sử dụng trên con máy, nằm ở /etc/gitconfig hoặc C:\ProgramData\Git\config

các biến này chứa một số thứ config để khi Git chạy thì sử dụng
cái hướng dẫn ở trên của thầy Long là để config lại cái "tên" hiển thị của các bạn trong lịch sử git và nó áp dụng mức global
tránh tình huống "ủa code này của ai đây"

nhấn vào xem ảnh

dùng Adjust List Indent để làm cho bullet indent cân đối hơn

Long Nguyễn Xuân — Tue, 26 Aug 2025 09:11:14 +0000

nhiều nhóm viết tài liệu, rất chủ quan, sử dụng chế độ mặc định của template, nên cái bài viết nhìn nó rất là mất cân đối và xấu như thế này

cái này do mỗi cấp, Word default "thụt" vào 0.25 inch

hãy dùng chức năng Adjust List Indent của Word, chỉnh lại indent vừa phải, ví dụ như mỗi level thì thụt vào (Indentation Left) thêm 0.1 thôi

ta sẽ được cái tài liệu nhìn cân đối như dưới

Daily report / daily stand up trong đồ án

Long Nguyễn Xuân — Wed, 08 Jan 2025 10:28:38 +0000

Khi đi làm vào tầm những năm 2025 này đa phần các bạn sẽ làm việc với mô hình Agile/Scrum, chi tiết về nó thì nói lúc khác, nhưng trong đấy có 1 thứ rất hay (*) gọi là "daily stand up"

Vì làm đồ án thì chúng ta chơi hệ remote working, và cũng hiếm team nào set được daily stand up qua video call, nên thường thì mình sẽ chơi daily stand up qua Discord,

cách làm như sau:

tạo 1 discord channel có tên daily-stand-up
mỗi ngày, người đầu tiên vào thực hiện daily stand up (hoặc gọi là daily report cũng được) thì tạo 1 thread với title YYYY-MM-DD và viết nội dung vào
các bạn còn lại reply theo format dưới

ví dụ

## DONE
// hôm nay vừa **xong** được việc gì, 
// nếu sp đó chưa công bố, hãy kẹp link vào 
// nếu không xong được gì thì ghi `N/A` 

## DOING 
// đang làm dang dở việc gì. 
chú ý viết đúng format 
- tiêu đề công việc 01 
  - original estimate: `n` h 
  - remain estimate:  `n` h 
  - plan done: `yyyy-mm-dd` 
- tiêu đề công việc 02
  - original estimate: `n` h 
  - remain estimate:  `n` h 
  - plan done: `yyyy-mm-dd` 

## ISSUE 
// có trở ngại gì khiến cho task bị trễ không ? 
// tuân thủ format
- tiêu đề: {text}
  + action: {text} 
     * plan: {yyyy-mm-dd}
## NEXT 
// mai dự kiến làm việc gì?
- việc 1 
  + plan: yyyy-MM-dd HH:mm 
- việc 2
  + plan: yyyy-MM-dd HH:mm

ví dụ

2025-01-08 

## DONE
`N/A` 

## DOING 
- code module quét QRCode checkin điểm danh #108
  - original estimate: 16 h 
  - remain estimate:  8 h 
  - plan done: 2025-01-09

## ISSUE 
- hôm trước đi bão ăn mừng việt nam vô địch, nên 2am mới về nhà,   
  gọi cho Khắc Hưng với Đức PHúc rồi đi ngủ thôi chứ không code nổi 
  - action: chủ nhật này bù tiến độ 

## NEXT 
- hoàn thành module QRCode #108 (**) 
  + plan: 2025-01-09 23:00  
- nghiên cứu về quẹt thẻ NFC bằng iPhone 
  + plan 2025-01-10

một nhóm làm tốt

(*) một số bạn sờ rum mát tơ đỉnh cao trí tuệ biến nó thành bullshit là chuyện khác 🐧

(**) cái #108 kia nếu như bạn dùng hệ tool quản lý dự án như jira / gitlab / azure board thì nhắn cái id này vào để tiện check

(***) nếu bạn thực sự giỏi, hãy tạo 1 cái tool / AI agent tự generate cái nội dung báo cáo này từ data jira/clickup/excel v.v. của dự án

gửi meeting request định kỳ

Long Nguyễn Xuân — Mon, 06 Jan 2025 16:15:58 +0000

sau này khi đi làm, bạn có thể gặp những người chuyên nghiệp (hoặc không 🐧) và họ có lịch làm việc rất dày đặc, nên để "họp" được với họ, bạn sẽ cần thứ gọi là "check lịch" và "book meeting request" (tên trong Outlook), hoặc bên vũ trụ Google gọi là "Calendar Event"

mặc dù trên công ty thì tui dùng Outlook 🪟 nhưng mà ở đây tui hướng dẫn sinh viên tạo Google Calendar Event 🐧

brief

https://calendar.google.com
Create / Event hoặc
Rê chuột chọn thời gian
nhập title, chọn hình thức lặp lại
nhập email người tham gia
nhập mục tiêu meeting

visual

update notepad++ portable

Long Nguyễn Xuân — Tue, 31 Dec 2024 03:53:25 +0000

update notepad++ portable thì extract ra 1 folder tạm, xong copy tất cả file vào folder chính, ngoại trừ config.xml & shortcuts.xml

nguồn: https://community.notepad-plus-plus.org/post/40809

if you update your portable version, please do not extract it directly to your portable folder.
extract it to a temporary location instead, e.g. your desktop, and copy everything from there to your portable folder except config.xml and shortcuts.xml

meeting notes - how

Long Nguyễn Xuân — Tue, 24 Dec 2024 02:03:13 +0000

Bài này được viết dành cho các bạn sinh viên làm đồ án phần mềm với thầy Long :D nhưng mà các bạn khác thấy có ích thì welcome nha :D

Nguyên tắc

Sau tất cả các cuộc họp đều phải công bố (gửi mail / post discord) cái meeting notes.
cái meeting notes này nên được gửi trong vòng 1h sau khi họp xong.
các thành viên khác phải có hành động xác nhận đã đọc và đồng ý với meeting notes, ví dụ như thả like
nếu không đồng ý với nội dung meeting notes, thì phải phản biện, còn khi không phản biện, thì phải tuân thủ nội dung đã thống nhất.

Nội dung

Meeting notes cần nêu rõ được 2 thứ

1. `KEY NOTES` - Quan điểm đã thống nhất

trong quá trình cùng nhau làm dự án, đôi khác bạn sẽ phát sinh những thứ A đúng, B cũng không sai, vậy trong dự án này làm theo cách A hay cách B?

câu trả lời là A hay B cũng được, nhưng phải thống nhất, và những cái thống nhất này phải được ghi thành văn bản, và công bố cho tất cả mọi người.

ví dụ:

dự án này tuân thủ quy trình gitflow được định nghĩa ở link (cái link mô tả riêng của nhóm, không được tự push code vào nhánh test và nhánh main, phải tạo meeting request và assign {account}

những thứ "quy tắc đồng thuận" này phải được thảo luận, thống nhất, ghi thành văn bản, và các cuộc họp thường dùng làm việc đó.

2. `TODO` - Việc phải làm

trong quá trình cùng nhau làm dự án, chúng ta sẽ có những việc "đột xuất" phát sinh ngoài cái plan ban đầu, lúc này phải có ai đó trong nhóm chịu trách nhiệm xử lý, vì tất cả mọi người đều "có việc" nên những cái "đột xuất" này phải được ghi thành văn bản để theo dõi (tracking / follow up) về sau với những thông tin cụ thể như

việc phải làm
người phụ trách
cam kết deadline

thư ký

làm ở công ty thì có thư ký, còn làm ở nhóm đồ án thì 5 đứa ngang hàng nên xoay tua mỗi lần meeting 1 đứa viết.

Hình thức

nếu đã setup discord server làm Communication Hub cho dự án
thì tạo 1 channel #meeting và tạo các thread theo từng ngày và post bài vào đó, convention là YYYY-MM-DD {tên meeting} hoặc YYYY-MM-DD cũng được

ví dụ:

còn đây là cái ví dụ sai của cái nội dung ở trên

nếu dùng hình thức khác để giao ví dụ như email, thì gửi lại email là được.

Outlook tìm mail nhận trong khoảng thời gian xác định

Long Nguyễn Xuân — Tue, 17 Dec 2024 02:16:48 +0000

nay được copilot dạy cho các tìm mail theo khoảng thời gian xác định

cú pháp:

received:>=MM/DD/YYYY AND received:<=MM/DD/YYYY

ví dụ: toàn bộ mail năm 2022 sẽ là received:>=01/01/2022 AND received:<=12/31/2022

có lẽ do máy mình đang để Regional Format là "English (United States)" nên nó vậy,
nếu máy đang set UI & Locale JP thì có lẽ cần đổi qua YYYY-MM-DD

DEV Community: Long Nguyễn Xuân

Thiết lập hệ thống quản lý task bằng jira

vì sao?

cách làm ngắn gọn

tiêu chí chấp nhận

mapping cấu trúc default của jira với cấu trúc công việc đồ án

chi tiết thao tác

estimate

calendar

Test Environment

Các điểm cần lưu ý về Business Rule

Định nghĩa

ví dụ

Các ví dụ khác về business rule

Trình bày đồ án như thế nào?

Ngắn gọn

chi tiết

Vì sao phải trình bày đồ án?

Vậy trình bày cái gì và như thế nào?

Nguyên tắc

OK, chốt lại cái dàn bài nó thế này

Vẽ quy trình nghiệp vụ bằng BPMN trong DrawIO

Vẽ quy trình nghiệp vụ bằng BPMN trong DrawIO

TLDR

hình ảnh

context

BPMN Hello world

tình huống thực tế

lý thuyết

Swimlanes (pool & lane)

Flow Elements

Connecting Objects (Kết nối giữa các thành phần):

áp dụng lý thuyết ta có sản phẩm như sau

Config git user.name để kiểm soát code

ngắn gọn

kết quả

giải thích chi tiết

dùng Adjust List Indent để làm cho bullet indent cân đối hơn

Daily report / daily stand up trong đồ án

gửi meeting request định kỳ

brief

visual

update notepad++ portable

meeting notes - how

Nguyên tắc

Nội dung

1. KEY NOTES - Quan điểm đã thống nhất

2. TODO - Việc phải làm

thư ký

Hình thức

Outlook tìm mail nhận trong khoảng thời gian xác định

1. `KEY NOTES` - Quan điểm đã thống nhất

2. `TODO` - Việc phải làm