Năm ngoái sau khi viết bài “My tool stack 2024”, tôi đã tạo một task như thế này trên Todoist của tôi:

Thoáng cái đã một năm trôi qua. Bài viết này sẽ nhằm cập nhật bộ tool stack của tôi xem có gì thêm, có gì bớt không.

💼 Personal Productivity

Bitwarden

Bitwarden hoàn toàn miễn phí. Tính năng cơ bản của một Password Manager cũng đều có, giao diện dễ sử dụng.

Sau khi sử dụng thử một tháng, tôi đã quyết định cancel subscription của Last Pass để chuyển hẳn sang sử dụng Bitwarden.

Đến giờ sau gần 1 năm chuyển nhà, tôi thấy rất happy.

Raycast

Nếu được phép chọn ra một “game changer” tool trong năm vừa rồi, thì tôi sẽ vote #1 cho Raycast. Tôi vốn là người ghét chuột.

Tôi sẽ cố gắng không động vào con chuột / trackpad nhiều nhất có thể.

Và Raycast sinh ra để phục vụ việc đó.

Ngoài ra hệ sinh thái với rất nhiều tiện ích mở rộng cũng giúp Raycast ghi điểm cực mạnh.

Một trong những tính năng của Raycast đó là ghi nhớ lịch sử Copy. Do đó tôi đã loại tool Pasty ra khỏi stack và sử dụng hoàn toàn Raycast.

Tương tự như vậy, tool để tìm emoji Rocket cũng bị cho vào dĩ vàng khi tất cả đều có trên Raycast.

Arc Browser

Dù còn điểm yếu ở phần quản lý bookmark, nhưng gần 1 năm qua trải nghiệm của tôi với Arc Browser là khá tích cực.

Tôi đặc biệt thích 3 tính năng sau:

• Ctrl + Tab sẽ quay lại tab mở gần nhất. Tôi thấy điều này đặc biệt tự nhiên. Vì khi làm việc chúng ta thường chỉ làm với khoảng 2-3 tab một lúc. Việc chuyển qua chuyển lại giữa 2 tab là điều tôi rất cần.

• Thanh search ở ngay trang hiện tại. Ở Chrome, mỗi khi muốn tìm kiếm cái gì, tôi phải mở tab mới, rồi mới search được. Nhưng với Arc, thì thanh search ở ngay trang hiện tại. UX làm tôi thấy dễ chịu hơn rất nhiều.

• Ẩn side bar. Đôi khi tôi chỉ muốn nhìn cái trang web hiện tại, và không có nhu cầu nhìn những thông tin thừa khác. Arc sẽ cho phép chúng ta ẩn toàn bộ các tab, chỉ hiện thị mỗi trang hiện tại.

⼰ Self-improvement

Obsidian

Về phần note talking thì năm vừa qua tôi đã chuyển hẳn qua dùng Obsidian.

Tôi cũng đã bỏ dùng Mindomo và chuyển hoàn toàn qua Mermaid trên Obsidian.

✍️ Content Creator

Screen studio

Tính năng mouse tracking của Screen Studio quả thực là hơn hẳn tất cả các đối thủ trong ngách phần mềm quan màn hình.

Nếu bạn cần phải làm video demo sản phẩm, thì không thể không dùng Screen Studio.

🧑‍💻 Dev Tools

Cursor AI

Bản thân tôi không thích AI.

AI làm cho phần nhiều người mất khả năng suy nghĩ độc lập.

AI làm cho những con người bình thường, nghĩ rằng họ đặc biệt.

Dù không thích nhưng cũng phải công nhận rằng AI đang giúp năng suất lao động tăng rất nhanh.

Bản thân tôi dùng Cursor AI như một dạng Assistant trong việc coding.

Tôi vẫn là người chỉ huy, nhưng việc thực thi thì để Cursor làm.

Tổng kết

Như vậy toolstack của tôi có sự thay đổi trong một năm như sau.

Bỏ không dùng: Lastpass, Pasty, Rocket, Mindomo, Lens

Tool mới: Bitwarden, Raycast, Arc Browser, Screen Studio, Cursor AI

Làn sóng sa thải nhân sự bắt nguồn từ khoảng năm 2022 kéo dài đến tận bây giờ. Khi ấy trong team mình luôn nói đùa với nhau một câu vui rằng “Optimize or to be optimized”.

Dẫn bài 2

Hôm trước có đọc được bài báo nói là Elon Musk thẳng tay sa thải nữ trợ lý 12 năm kinh nghiệm vì đòi tăng lương. Thế mới thấy sự hiệu quả và giá trị mang lại mới là điều quan trọng.

Dẫn bài 3

Từ hồi đọc nhiều báo cáo doanh nghiệp tôi mới biết rằng các chi phí ảnh hưởng đến lợi nhuận của một doanh nghiệp có thể chia thành mấy mục sau:

• Giá vốn hàng bán

• Chi phí quản lý doanh nghiệp

• Chi phí bán hàng

Giá vốn hàng bán là thứ khó giảm vì phụ thuộc nhiều vào nguyên liệu đầu vào. Chi phí bán hàng thì cũng khó giảm nếu sản phẩm của doanh nghiệp chưa có thương hiệu lớn. Thứ có thể giảm được là chi phí quản lý doanh nghiệp. Đọc nhiều báo cáo mới thấy có những doanh nghiệp khá nhỏ, mô hình kinh doanh hết sức đơn giản mà chi phí quản lý doanh nghiệp cực kỳ cao.

Tôi đã dùng bản trả phí của Todoist được 6 năm

Tôi bắt đầu mua bản trả phí của Todoist từ năm 2020, đến nay đã là 6 năm. Nhìn lại chặng đường sử dụng cũng rất vui. Thậm chí năm 2021 còn được Todoist tặng cho một cái cốc mà tôi hồi hộp nhận đợi cả 3 tháng trời mới ship về đến Việt Nam.

Dùng bản trả phí thì được cái không bị giới hạn gì cả, tạo bao nhiêu project cũng được.

Tuy nhiên … dường như tôi đang dùng chưa được hiệu quả cho lắm. Tôi tạo khá nhiều nested project, rồi sau một thời gian có những project chỉ còn một vài task recurring, có những project thì chỉ còn backlog.

Quyết định cấu trúc lại Todoist và bỏ thuê bao

Sau khi cân nhắc, tôi quyết định sẽ bỏ thuê bao năm, quay lại dùng bản miễn phí, và ngồi cấu trúc lại Todoist.

6 năm trước tôi mua bản trả phí vì muốn số project được tạo không bị giới hạn, 6 năm sau tôi bỏ bản trả phí vì muốn số project bị giới hạn.

Tôi nghĩ sự hạn hẹp trong không gian sẽ giúp chúng ta trở nên optimize hơn. Không phải ngẫu nhiên mà những chương trình viết từ thuở khai thiên lập địa về lập trình lại chạy tốt đến như thế. Hàm grep, hàm find trong Unix là những masterpiece. Vì sao vậy? Vì thời đó những Dennis Ritchie và Ken Thompson chỉ có vài mẩu RAM để chạy chương trình của họ.

Dùng Git cho việc đồng bộ

Lúc mới tìm hiểu Obsidian, tôi thấy có tính năng đồng bộ vault lên cloud, tuy nhiên phải trả phí. Tôi nghĩ là vậy cũng như bao app khác, không có gì đặc biệt. Tuy nhiên sau khi phát hiện ra có thể dùng git để quản lý vault, tôi đã thay đổi quan điểm.

Ví dụ, tôi muốn dùng git và GitHub làm công cụ quản lý và lưu trữ dữ liệu, thì làm các bước như sau:

Bước 1: Tạo repo trên Github.

Bước 2: Clone repo về máy.

Bước 3: Cài plugin Git trên Obsidian.

Bước 4: Chọn repo vừa clone về làm vault.

Bước 5: Cài đặt thời gian interval để sync lên Github.

Vậy là xong rồi, tôi đã có một vault “cloud” hoàn toàn miễn phí.

Dùng Vimium để không phải động vào chuột

Nếu bắt bạn chỉ được dùng bàn phím, mà không được dùng chuột hay touchpad, bạn sẽ dùng các phần mềm trên máy tính thế nào?

Câu trả lời có thể là hotkeys, hoặc Vimium.

Vimium nổi tiếng trên Chrome bao năm nay.

Tôi mới phát hiện có một plugin mới được phát triển khoảng 1 năm nay để làm Vimium trên Obsidian: https://github.com/karstenpedersen/obsidian-vimium

Bạn có thể cài dùng thử.

Nghỉ việc chưa bao giờ là chuyện dễ dàng với bất kỳ ai. Cá nhân tôi cũng phải trải qua cảm giác ấy hai lần vào năm 2018 và 2021. Nhớ về những giai đoạn đó, tôi thấy có rất nhiều yếu tố chi phối quyết định nghỉ việc của bản thân. Nhưng dường như tôi đã quá đề cao một vài yếu tố, mà quên đi hoặc đánh giá thấp những yếu tố quan trọng khác.

Để sai lầm đó không lặp lại trong tương lai, tôi đã tự xây dựng cho bản thân một framework có tên “Nghỉ việc framework” (bạn bấm vào đường dẫn để ra file Google Spreadsheet nhé).

Để xây dựng ra được framework bên trên, tôi làm theo ba bước như sau:

• Bước 1: Xác định những yếu tố then chốt ảnh hưởng đến quyết định nghỉ việc

• Bước 2: Đánh trọng số cho các yếu tố

• Bước 3: Định kì đánh giá, chỉnh sửa, và bổ sung cho framework

Bước 1: Xác định những yếu tố then chốt ảnh hưởng đến quyết định nghỉ việc

Mỗi cá nhân mỗi hoàn cảnh, vì thế mà yếu tố then chốt ảnh hưởng đến quyết định nghỉ việc cũng khác nhau. Với cá nhân tôi, tôi bị ảnh hưởng bởi các nhóm yếu tố sau:

• Benefits (đãi ngộ)

• Grow opportunities (cơ hội phát triển)

• Culture (văn hoá công ty)

• Work-life balance (cân bằng cuộc sống - công việc)

• Feeling (cảm giác)

Benefits (đãi ngộ)

Đối với những người trẻ như tôi, đãi ngộ tốt luôn là một trong những yếu tố then chốt trong việc quyết định đi hay ở một công ty. Đãi ngộ bao gồm:

• Salary (lương thưởng): Trong cuốn sách “Drive: the Surprising Truth About What Motivates Us”, tác giả Danial Pink cho rằng việc được trả lương thưởng tương xứng với năng lực là yếu tố kiên quyết để giúp cho một nhân viên yên tâm làm tốt công việc của họ.

• Time Flexibility (thoải mái về mặt thời gian): Do từ trước giờ tôi đều làm việc ở những công ty thoải mái về mặt thời gian nên đây cũng là yếu tố rất quan trọng với tôi.

• Other benefits (các phúc lợi khác): Công ty có đóng bảo hiểm trên lương đầy đủ không, có hỗ trợ học phí học tập hay không, vv. (Với các bạn nữ thì tôi thấy các bạn ấy rất quan tâm đến chế độ thai sản).

Grow opportunities (cơ hội phát triển)

Quan trọng tương đương với đãi ngộ là cơ hội phát triển bản thân. Với tôi, các yếu tố then chốt trong mục này là:

• Functional skills (kĩ năng chuyên môn): Với tôi, trong khoảng thời gian này của sự nghiệp, kĩ năng chuyên môn vẫn là yếu tố có vai trò rất quan trọng. Tôi quan niệm rằng sẽ không thể là một người lãnh đạo tốt, nếu chưa từng là một nhân viên giỏi.

• Leadership (cơ hội lãnh đạo): Có cơ hội lãnh đạo sẽ giúp chúng ta tạo ra được nhiều ảnh hưởng hơn, do đó nâng cao được giá trị bản thân hơn.

• Ownership (khả năng tự chủ): Tôi muốn được làm chủ những công việc của bản thân, hoặc có càng ít sự phụ thuộc vào bên thứ ba càng tốt.

Culture (văn hoá công ty)

Trong mục này tôi có ba yếu tố then chốt:

• Manager (sếp): tôi có cảm thấy thoải mái với người sếp hiện tại của mình hay không.

• Co-worker (đồng nghiệp): đồng nghiệp có vui vẻ hoà đồng, có cùng chung chí hướng hay không.

• Job chores (việc nhàm chán): làm việc trong một tổ chức sẽ không thể tránh khỏi việc phải dành thời gian cho những việc mà tôi cảm thấy là có phần nhàm chán như họp hành, báo cáo. Tôi cần xác định xem mình có chấp nhận được những đánh đổi này hay không.

Work-life balance (cân bằng cuộc sống - công việc)

Cuộc sống có nhiều khía cạnh. Ví dụ như tôi rất thích thể thao, hay thích nghiên cứu rồi viết lách. Nên nếu công việc nào mà dành mất thời gian các hoạt động đó của tôi thì đó sẽ làm một điểm trừ lớn. Tôi thấy có hai yếu tố chính trong mục này:

• Overtime (làm ngoài giờ): công việc có yêu cầu phải làm ngoài giờ nhiều hay không.

• Location (vị trí): nếu là làm việc onsite, thì tôi có mất nhiều thời gian để di chuyển từ chỗ tôi ở đến nơi làm việc hay không.

Feeling (cảm giác)

Cuối cùng là yếu tố vô cùng quan trọng: cảm giác. Những lần nghỉ việc trước, tôi hầu như chỉ dựa vào yếu tố này. Cảm giác giống như mẩu giấy quỳ tím, giúp tôi nhận ra rằng mình có đang ba “dơ” hay không. ôi chia cảm giác thành ba yếu tố nhỏ hơn như sau:

• Proud (tự hào): tôi có cảm thấy tự hào với những gì mà công ty đang làm hay không.

• Confident (tự tin): tôi có cảm thấy tự tin nói với mọi người rằng tôi đang làm ở công ty này hay không. Hoặc tôi có tự tin để giới thiệu một người bạn của tôi vào làm việc ở công ty hiện tại hay không.

• Instinct (trực giác): trực giác là thứ nằm trong vô thức, được “lập trình” cả triệu năm. Do đó, trực giác đánh giá không tốt, thì rất có thể là đang có vấn đề.

Bước 2: Đánh trọng số cho các yếu tố

Không phải yếu tố nào cũng quan trọng như nhau. Lấy ví dụ phần growth opportunities, thời điểm hiện tại tôi quan trọng việc được phát triển phần functional skills hơn so với việc phát triển kĩ năng leadership.

Do đó tôi cần đánh trọng số dựa trên độ ưu tiên của từng yếu tố, sao cho khi cộng tổng các trọng số, ta được 100%. Bạn có thể mở file Google Spreadsheet ra xem cho dễ hình dung nhé.

Bước 3: Định kì đánh giá, chỉnh sửa, và bổ sung cho framework

Giống việc khám sức khoẻ hàng năm, tôi cũng thực hiện đánh giá độ hạnh phúc của mình với công việc hiện tại hàng quý. Đồng thời tôi cũng chỉnh sửa lại framework để thêm / bớt yếu tố, cũng như chỉnh lại phần trọng số sao cho phù hợp với nhu cầu của bản thân.

Mỗi một yếu tố sẽ được đánh giá trên thang điểm từ 0-10. Điểm số cuối cùng sẽ là trung bình của trọng số nhân với điểm của từng yếu tố. Kết luận cuối cùng được đưa ra dựa trên thang điểm bên dưới.

Kết luận

Framework bên trên là một công cụ đắc lực giúp tôi nhận ra những vấn đề một cách sớm nhất có thể, từ đó có những hành động kịp thời để khắc phục. Nếu sau khi đánh giá, tôi thấy điểm đang ở vùng warning, tôi có thể có những hành động như ngồi với manager để thảo luận về phương hướng. Còn nếu tình trạng dangerous diễn ra một thời gian 1-2 quý liên tiếp mà không thể khắc phục, có lẽ đây sẽ lúc quyết định nghỉ việc được cân nhắc tới.

✌️ Tạm biệt

Chủ đề của tuần này kết thúc ở đây. Hẹn gặp lại độc giả vào giờ này tuần sau. Nếu bạn có bất kỳ thắc mắc nào về bài viết, hãy để lại bình luận ở bên dưới nhé. Bạn cũng có thể kết nối với tôi thông qua LinkedIn hoặc Twitter.

Trong bài viết tuần này, tôi sẽ tiết lộ bộ công cụ (chủ yếu là các phần mềm) mà tôi đang thường xuyên sử dụng trong học tập và làm việc.

Có khoảng 20 công cụ sẽ được tôi đề cập tới, chúng được chia thành 4 mục như sau:

• 💼 Personal Productivity - các công cụ giúp nâng cao hiệu quả làm việc

• ⼰ Self-improvement - các công cụ giúp tôi tự cải thiện bản thân mỗi ngày

• ✍️ Content Creator - các công cụ giúp việc sáng tạo nội dung dễ dàng hơn

• 🧑‍💻 Dev Tools - các công cụ không thể thiếu của một kỹ sư phần mềm

Nào chúng ta cùng bắt đầu👇

⚠️ Đừng quá lạm dụng công cụ

Trước khi đi vào phần chính của bài viết, tôi xin được nói một chút về quan điểm sử dụng công cụ.

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble. - Ralph Waldo Emerson.

Có triết gia người Mỹ đã từng nói rằng một Principle (nguyên tắc) thì có thể có nhiều Method (phương pháp). Nay tôi bổ sung thêm một vế nữa, là một Method (phương pháp) thì cũng có thể có nhiều Tool (công cụ).

Do đó, khi sử dụng một công cụ, điều quan trọng không phải là công cụ đó xấu đẹp thế nào, được ai gợi ý, nhiều người dùng không, mà quan trọng là công cụ đó đang được dùng trong phương pháp nào, giải quyết vấn đề gì trong phương pháp đó.

Nếu nắm được điều đó, chúng ta sẽ tránh được việc dùng quá nhiều công cụ cho cùng một việc, hoặc là chẳng biết một công cụ gì để mà dùng.

💼 Personal Productivity

🎯 Quản lý mục tiêu với Google Spreadsheet

Sống cần có mục tiêu. Đấy là nguyên tắc. Còn vì sao lại như thế, thì mời bạn đọc nghe mấy video của anh Hiếu Ti Zi đã giải thích rất cặn kẽ:

• #2 Cuộc sống không mục tiêu

• #103 Còn mục tiêu, còn hạnh phúc

• #148 Chọn mục tiêu để theo đuổi

Tuy nhiên, trong các video đó anh Hiếu không đề cập đến phương pháp thiết lập mục tiêu ra sao. Với cá nhân tôi, phương pháp thiết lập mục tiêu mà tôi đang dùng là OKRs.

Và công cụ tôi đang dùng để quản lý là Google Spreadsheet. Cách này cũng được chính Google áp dụng cho việc thiết lập mục tiêu cho nhân viên và đội nhóm của họ.

📋 Quản lý công việc với Todoist & Google Calendar

Thường thì một ngày sẽ có 2 loại công việc.

Loại thứ nhất là có công việc có time boundaries, ví dụ:

• 7:00 - 9:00 - Lên lớp tập JiuJitsu

• 10:00 - 10:15 - Họp mặt đầu tuần

• 16:30 - 17:30 - Họp cập nhật tiến độ dự án X

Loại thứ hai là công việc không bị giới hạn bởi time boundaries, miễn là trong ngày hôm đó hoàn thành là được, ví dụ:

• Cài đặt Sentry cho phần code backend

• Đi thay dầu nhớt xe máy định kì

• Chúc mừng sinh nhật Jon

👉 Đối với loại thứ nhất, tôi dùng Google Calendar. Còn với loại thứ hai, tôi dùng Todoist.

Ngoài ra, tôi còn dùng Todoist cho việc capture thông tin. Bất cứ khi nào trong đầu tôi có một ý tưởng gì đấy, hay khi tôi có một task nào đấy, tôi sẽ ghi ngay vào hòm thư Inbox của Todoist. Todoist chính là công cụ để tôi hiện thực hoá bước Capture trong cả hai phương pháp Getting Things Done và Second Brain.

⚛️ Các phần mềm khác

• LastPass - Đây là phần mềm quản lý mật khẩu và các thông tin cá nhân tôi đã dùng được khoảng hơn 3 năm nay. Nếu bạn đọc chưa dùng bất kỳ một phần mềm quản lý mật khẩu nào, thì tôi khuyên chân thành bây giờ là lúc dùng vẫn chưa muộn.

• Pasty - Một trong những tác vụ mà tôi dùng nhiều nhất khi làm việc, đấy là copy và paste. Tuy nhiên, với tính năng có sẵn của hầu hết các máy tính, tôi chỉ có thể copy được một nội dung duy nhất tại một thời điểm. Pasty giúp tôi có thể copy nhiều nội dung cùng một lúc.

• Rocket - Không biết bạn đang tìm Emoij trên máy Mac kiểu gì? Tôi thì có hai cách, hoặc là dùng tính năng có sẵn của máy Mac (tổ hợp phím Ctrl + Alt + Space), hoặc dùng phần mềm Rocket.

• MonitorControl (chỉ có trên MacOS) - Nếu ai đang dùng màn hình rời, có lẽ sẽ gặp vấn đề trong chuyện chỉnh ánh sáng. Với MonitorControl, việc chỉnh ánh sáng trên các monitor trở nên siêu dễ dàng.

⼰ Self-improvement

📖 Đọc sách với Kindle và Raindrop.io

• Kindle - Tôi dùng phần mềm Kindle để đọc sách. Tôi cài Kindle trên tất cả các thiết bị, để bất cứ khi nào, bất cứ đâu tôi cũng có thể tiếp tục đọc được những phần mà tôi đang đọc dở.

• Goodreads.com - Kindle của Amazon, Goodreads cũng vậy. Đây là nơi để viết và xem review về các cuốn sách. Nếu bạn cũng đang dùng GoodReads, thì có thể connect với tôi ở đây nhé.

• Raindrop.io - Khi lưới web, đôi khi tôi sẽ gặp một ý rất tâm đắc mà tôi muốn lưu lại. Lúc này tôi có 2 lựa chọn. Lựa chọn thứ nhất, là tôi mở Todoist ra và save vào hòm thư inbox. Cách này lúc trước tôi vẫn dùng. Tuy nhiên, dạo gần đây tôi sử dụng thêm một công cụ nữa, giúp cho việc lưu highlight dễ hơn nhiều, công cụ ấy có tên là raindrop.io. Với công cụ này, tôi chỉ cần bôi highlight đoạn text, click chuột phải rồi bấm lưu lại là xong. Các thao tác hoàn toàn ở trong trình duyệt, không phải mở app bên ngoài.

📝 Ghi nhớ dài hạn với Anki

Anki là phần mềm mã nguồn mở, được phát triển dựa trên phương pháp học lặp lại Space Repetition.

Điểm vượt trội của Anki so với các tool khác là khả năng tuỳ chỉnh gần như không giới hạn. Có hẳn một danh sách Anki Awesome chứa link đến các plugins, các decks có sẵn mà bạn có thể sử dụng được luôn.

Một số plugin mà tôi đang dùng:

• Anki Connect - cung cấp API cho phép tương tác với dữ liệu.

• Genanki - thư viện viết bằng Python cho phép tạo Anki decks bằng lập trình.

🧠 Sơ đồ tư duy với Mindomo

Tôi còn nhớ lần đầu biết đến sơ đồ tư duy là từ hồi còn học cấp 2. Khi ấy, anh trai tôi - lúc bấy giờ đang học cao đẳng trên thành phố - mang về cho tôi quyển sách tên là “Tôi tài giỏi bạn cũng thế” 🤣.

Quê tôi hồi ấy không có internet, nên những gì được mang về từ thế giới thành thị thực sự làm tôi cảm thấy như “bừng nắng hạ”. Mặc dù, thời gian qua đi, nhận thức về cuốn sách cũng khác đi, nhưng điều chưa bao giờ thay đổi trong tôi đấy là ấn tượng về việc sử dụng sơ đồ tư duy.

Mindomo có cả phiên bản web dùng online, và app dùng được cả khi offline. Ngoài ra, còn có một tool nữa tương tự có tên XMind, bạn đọc cũng có thể tham khảo.

~~

1 phút lạc đề: Không biết bạn có để ý đến cái emoij (⼰) tôi chọn cho phần self-improvement này không? Nó là một chữ trong tiếng Trung, bính âm là (jǐ), đọc là Kỷ, tiếng việt nghĩa là “sở hữu”, tiếng anh là “self”. Mấy từ như tự kỷ, ích kỷ đều liên quan đến chữ này. Ngoài ra, Kỷ cũng là một trong 10 thiên can. Nên ai có năm sinh kết thúc bằng số 9 như là 1999, 1989 thì năm sinh âm lịch cũng có chữ Kỷ. Tuần trước tôi có viết một bài kể về trải nghiệm của tôi với quá trình học tiếng Trung, cũng thú vị lắm đấy!

✍️ Content Creator

Kể từ khi viết bài đều đặn hàng tuần, tôi đã học được rất nhiều kĩ năng mới, phương pháp mới, cùng với đó là rất nhiều công cụ mới. Dưới đây là một số công cụ mà tôi thường xuyên sử dụng:

• Canva.com - Làm thumbnail, làm ảnh động gif, làm hiệu ứng animation tất cả tôi đều làm hết trên Canva. Tôi đặc biệt thích tính năng tạo hiệu ứng Morph. Bạn có thể xem chị này hướng dẫn. Hoặc là xem tôi thuyết trình về lịch sử máy tính, cũng dùng Canva để làm slide.

• Substack.com - Dĩ nhiên rồi, không thể không nhắc đến Substack. Ngoài tính năng chính là để viết, Substack còn có nhiều tính năng khác như chèn Voice Over, hay làm Podcast. Trong tương lai, tôi sẽ đưa dần những tính năng đó vào trong blog của mình.

• Namecheap.com - Tôi mua tên miền trên Namecheap vì nó rẻ. Tên miền lequockhanh.com của tôi cũng được mua ở trên này.

• CloudFlare Page - Nếu bạn truy cập vào tên miền lequockhanh.com của tôi, bạn sẽ thấy một cái website xấu hoắc mà tôi tự code thuần bằng HTML. Những trang web như thế gọi là web tĩnh - static web. Có rất nhiều dịch vụ hỗ trợ việc dựng lên một trang web tĩnh hoàn toàn miễn phí như là Github Pages, Netlify, Vercel, vv. Còn tôi thì lựa chọn CloudFlare Pages, do tôi còn dùng nhiều dịch vụ khác của CloudFlare.

• OBS - Open Boardcaster Software là một phần mềm mã nguồn mở giúp cho việc live stream rất dễ dàng. Tôi dùng OBS để phát sóng trực tiếp lên Youtube.

🧑‍💻 Dev Tools

Cuối cùng không thể thiếu là những công cụ phục vụ cho công việc chính của tôi - một kỹ sư phần mềm.

• VSCode - Phần lớn thời gian là tôi làm việc trên VSCode. Không những miễn phí, VSCode còn có bộ thư viện plugin cực kỳ phong phú. Dạo gần đây, tôi có sử dụng 2 plugin là SSH Remote, và Dev Container. Hai plugin này đã hoàn toàn thay đổi cách tôi lập trình bấy lâu nay.

• Tmux - Công cụ dành nhiều thời gian thứ hai sau IDE, đó là terminal. Và phần mềm tôi đang sử dụng để quản lý terminal đó là Tmux.

• Cloudflare 1.1.1.1 - Như tôi đã đề cập ở phần trước, tôi dùng khá nhiều sản phẩm của Cloudflare. Cloudflare 1.1.1.1 giúp bypass việc bị chặn DNS queries từ các nhà mạng.

• Cloudflare ZeroTrust - Tôi thường dùng tính năng mở Tunnel của Cloudflare ZeroTrust. Khi ấy tôi có thể đưa một service chạy dưới máy local có thể được access trên internet, nhưng vẫn đảm tính bảo mật nhờ lớp xác thực của CloudFlare.

• Lens - Nếu ai làm việc nhiều với Kubernetes chắc hẳn không còn xa lạ gì với phần mềm này. Lens cung cấp giao diện trực quan để kết nối đến các K8S cluster.

📢 Weekly shoutouts

Dưới đây là một vài bài viết thú vị mà tôi đã đọc được trong tuần vừa rồi.

• Quản lý công việc với phương pháp Gettings Thing Done by Tuanmon on Tuanmon.com - Bài viết có tính thực tế cao trong quá trình áp dụng phương pháp Gettings Thing Done trong quản lý công việc.

• Cách Di tích Nhà tù Hoả Lò làm truyền thông by Thanh-Huyen Pham on minj 4dult - Tôi rất thích những hình vẽ trong bài viết này.

✌️ Tạm biệt

Chủ đề của tuần này kết thúc ở đây. Hẹn gặp lại độc giả vào giờ này tuần sau. Nếu bạn có bất kỳ thắc mắc nào về bài viết, hãy để lại bình luận ở bên dưới nhé. Bạn cũng có thể kết nối với tôi thông qua LinkedIn hoặc Twitter.

Sở dĩ có cuộc họp này vì các team business có quá nhiều pain points, hầu hết là liên quan đến chuyện số hoá, tự động hoá các quy trình nghiệp vụ.

Có 3 hướng giải pháp được đưa ra:

1. Áp dụng ERP (Enterprise Resource Planning)

2. Sử dụng Workflow automation & RPA (Robotic Process Automation)

3. Chuẩn hoá quy trình nghiệp vụ với BPMN (Business Process Modeling Notation)

Với giải pháp số 1, tôi đã từng viết ở bài “Từ ERPNext đến Frappe framework”. Giải pháp số 3, là cách để chuẩn hoá cách dùng diagram, tham khảo tại đây.

Riêng giải pháp số 2, chúng ta sẽ tìm hiểu kĩ trong bài viết tuần này.

Automation

Mọi thứ bắt đầu từ một nhu cầu căn bản: Tự động hoá (Automation).

Có lẽ, phần lớn bài toán về optimize của một doanh nghiệp thì đều liên quan đến automation.

Cốt lõi của tự động hoá xoay quanh 2 câu hỏi chính: Khi nào (WHEN?) và Làm gì (THEN do what?).

Workflow

Một workflow là một tập hợp các bước cần phải thực hiện để hoàn thành một quy trình nghiệp vụ (process). Mà khoan, vậy workflow khác gì với process?

Process trả lời cho câu hỏi: kết quả là gì. Còn workflow trả lời cho câu hỏi: làm như thế nào. Khi ấy, nói đến workflow ta thường phải nhắc đến cụ thể một công cụ nào đó.

Hãy nhìn ví dụ bên dưới để hình dung rõ hơn.

Workflow Automation

Như vậy khi kết hợp “workflow” và “automation” ta hiểu đó là việc tự động hoá workflow của một process.

Có thể lấy một vài ví dụ về workflow automation như sau:

• Theo dõi brand mentioning trên social media trên GSheet.

• Tạo reports hàng tuần về tiến độ công việc.

• Gửi email cho khách hàng để xin review sau khi họ hoàn thành mua một món hàng.

Trên thị trường hiện tại có một vài product tiêu biểu giải quyết bài toán workflow automation, có thể kể đến như:

• UIPath

• Zapier

• IFTTT

RPA (Robotic Process Automation)

Ai từng xem bộ phim Modern Times của vua hề Sạc Lô, chắc sẽ nhớ cảnh vị vua hề bị đưa vào một cái máy cho ăn tự động (feeding machine). Cái máy đó sẽ lần lượt cho người dùng ăn hết món này đến món khác, rồi tự động lau miệng.

RPA, in one way or another, cũng giống như cái feeding machine.

Khác với workflow automation khi logic thường được xử lý ở phía backend, RPA thì cần có sự tham gia của yếu tố “robotic”. Robotic thường được giải quyết bằng AI, machine learning, bots, vv.

Dưới đây là một vài ứng dụng ví dụ về RPA:

• Chatbot: Chatbot được tạo ra để trả lời những câu hỏi thường gặp của người dùng.

• Scan CV của ứng viên: Thay vì cần con người để lọc các CV tiềm năng, các công ty có thể dùng RPA để scan, trước khi đưa các CV đó vào trong process của team nhân sự.

• Crawl data: Những con bot sẽ tự động đi thu thập dữ liệu trên tập các website phục vụ cho mục đích analytics.

Tham khảo

• Workflow automation: What it is, why it matters, and how you can use it

• Robotic process automation: RPA meaning and how to integrate it into your business

* This file contains the magic bits required to compute the global loadavg
* figure. Its a silly number but people think its important. We go through
* great pains to make it work on big machines and tickless kernels.

Quote phía trên được trích từ file loadavg.c trong source code của Linux kernel. Tác giả muốn nói rằng load average là một con số ngớ ngẩn (silly), nhưng rất nhiều người lại nghĩ là nó quan trọng.

Vậy load average là gì? Và tại sao trong source code của Linux lại cho rằng nó không thực sự quan trọng như mọi người vẫn nghĩ?

Load Average là gì?

Thông thường, khi hệ thống gặp vấn đề, việc đầu tiên cần làm là đi kiểm tra xem có bị thiếu resources hay không. Và cách dễ nhất để biết điều đó là kiểm tra load average.

Nào hãy cùng mở terminal và chạy câu lệnh bên dưới:

$ uptime
08:31:10 up 60 days, 18:16,  1 user,  load average: 16.55, 8.11, 4.28

Giải thích phần output một chút:

• 08:31:10: giờ hiện tại lúc chạy câu lệnh

• up 60 days 18:16: thời gian hệ thống đã chạy (60 ngày 18 tiếng 16 phút)

• 1 user: hiện tại đang có 1 người dùng login vào

• load average: 16.55, 8.11, 4.28 - thể hiện load average trung bình trong 1 phút, 5 phút, và 15 phút gần nhất.

Sau khi kiểm tra tôi thấy load average trong 1 phút gần nhất có vẻ cao, nên đã kết luận hệ thống bị chậm là do thiếu CPU. Tuy nhiên có vẻ mọi thứ không giống như tôi nghĩ.

Tại sao Load Average lại không quan trọng như nhiều người vẫn nghĩ?

Rất nhiều người khi đề cập đến load average, họ sẽ nghĩ ngay đến thông số của CPU. Tuy nhiên điều này không chính xác.

Trong những phiên bản kernel Linux đầu tiên, load average đúng là CPU load average thật. Tuy nhiên, vào năm 1993, sau một bản patch ở version 0.99.14, load average đã được thay đổi cách tính để trở nên tổng quát hơn. Lúc này, nó không chỉ là thông số về CPU nữa, mà còn phản ánh thực trạng của các resource khác như disk I/O, locks.

Do đó, việc tôi ngay lập tức kết luận load cao là do thiếu CPU là một kết luận chưa đủ căn cứ, và thực tế cũng đã chứng minh như vậy.

Vậy có thể kết luận gì khi nhìn vào load average?

Nếu chỉ nhìn vào load average, ta chỉ có thể trả lời được cho hai câu hỏi:

Câu hỏi 1: Có phải hệ thống đang thiếu resources hay không?

Để trả lời được câu hỏi này, ta so sánh load average của hệ thống lúc có vấn đề với lúc hệ thống chạy bình thường. Nếu nó cao hơn, có nghĩa là hệ thống đang quá tải.

Câu hỏi 2: Hệ thống có vấn đề từ khi nào?

Để trả lời câu hỏi này, ta cần nhìn vào cả 3 thông số 1m, 5m, và 15m.

• Nếu 1m load average lớn hơn 5m và 15m load average, khả năng là vấn đề đang xảy ra.

• Nếu 1m load average thấp hơn 5m và 15m load average, khả năng là thời điểm xảy ra vấn đề đã trôi qua.

Tổng kết

Brendan Gregg - tác giả của nhiều cuốn sách nổi tiếng về monitoring hệ thống - có nói rằng: “Don't spend more than 5 seconds for load average”. Dịch ra là “Không dành quá 5 giây cho load average”. Load average nên chỉ dừng lại ở mức entrypoint cho quá trình troubleshooting mà thôi.

Vậy sau khi giành ra 5 giây để kiểm tra load average, chúng ta cần làm gì tiếp theo? Xin phép được hẹn bạn đọc trong một bài viết khác.

Tham khảo

• Phần lớn bài viết được tham khảo ở Linux Load Averages: Solving the Mystery

• Tool tôi vẽ comic dùng Canva Comic Strip

Không chỉ là do có liên quan đến nền kinh tế của một đất nước, mà còn là vô cùng nhiều thách thức về mặt công nghệ.

Trong chuỗi bài viết này, chúng ta cùng nhau đi tìm hiểu cách thức hoạt động của thị trường chứng khoán ở Việt Nam nhé.

Subscribe now

Tổng quan thị trường chứng khoán

Thị trường chứng khoán chia làm 2 cấp: sơ cấp (primary market) và thứ cấp (secondary market).

Thị trường sơ cấp là nơi các doanh nghiệp huy động vốn lần đầu thông qua việc IPO (initial public offering). Còn thị trường thứ cấp là nơi các nhà đầu tư mua bán cổ phiếu đã phát hành trên các sàn giao dịch chứng khoán, hoặc sàn giao dịch OTC.

* Sàn OTC là sàn mà bên mua và bên bán tự thoả thuận với nhau, mà không thông qua các sàn giao dịch chứng khoán như HOSE, hay HNX.

Các tác nhân trên thị trường chứng khoán

Có 4 tác nhân chính trên thị trường chứng khoán, bao gồm:

• Nhà đầu tư / nhà đầu cơ

• Công ty chứng khoán. Ví dụ VnDirect, SSI, DNSE

• Sàn chứng khoán. Ví dụ: HOSE, HNX, UPCOM

• Uỷ ban chứng khoán nhà nước

Trước 2008, hoạt động mua bán diễn ra như thế nào?

Năm 2008, sở giao dịch chứng khoán Hồ Chí Minh (HOSE) mới chính thức triển khai việc kết nối giao dịch trực tuyến. Vậy từ năm 2000 đến năm 2008, thì giao dịch kiểu gì?

Khi ấy, các nhà đầu tư phải liên hệ với môi giới ở các công ty chứng khoán, rồi nhờ họ gọi điện lên sở giao dịch chứng khoán để đặt lệnh. Khi nhu cầu giao dịch chứng khoán tăng lên như những năm 2006-2007, nghề môi giới đúng là vua của mọi nghề. Nhiều khi để được ưu tiên đặt lệnh các nhà đầu tư phải “bồi dưỡng” thêm cho các môi giới.

Xem mấy bộ phim như là Sói già phố Wall, hay Pursuit of happiness sẽ thấy điều này.

Luồng hoạt động của hệ thống giao dịch chứng khoán

Kể từ năm 2008, hệ thống giao dịch online đi vào hoạt động đã cho phép nhà đầu tư mua bán trên thị trường thứ cấp dễ dàng hơn nhiều.

Ngoài 4 tác nhân chính tôi đã nêu ở phần trên, để hệ thống giao dịch chứng khoán hoạt động được, cần có thêm vài tác nhân nữa, chẳng hạn như Trung tâm lưu ký và bù trừ, Ngân hàng thanh toán.

Có thể mô phỏng luồng hoạt động bằng lời như sau:

Khi IPO

• Công ty tư nhân đăng ký với trung tâm lưu ký để IPO

• Công ty tư nhân nhờ một ngân hàng đầu tư nào đó để đi mời chào bán cổ phần với giá cao nhất có thể

• Nhà đầu tư được mời chào và mua cổ phần, trở thành cổ đông

• Từ lúc IPO đến khi niêm yết, cổ đông có thể mua bán cổ phần trên thị trường OTC

• Công ty tiến hành niêm yết lên sàn chứng khoán, lúc này cổ đông không được mua bán trên OTC nữa

• Nếu muốn mua bán, cổ đông phải đăng ký với trung tâm lưu ký để đưa cổ phần thành cổ phiếu trên sàn chứng khoán

Khi đăng ký tài khoản chứng khoán

• Nhà đầu tư mở tài khoản chứng khoán tại một công ty chứng khoán nào đó

• Công ty chứng khoán đem thông tin của khách hàng lên trung tâm lưu ký để tạo tài khoản lưu ký

• Công ty chứng khoán tạo tài khoản ngân hàng cho nhà đầu tư tại một ngân hàng thương mại

Khi giao dịch chứng khoán

• Nhà đầu tư nạp tiền vào tài khoản chứng khoán, tiền sau đó sẽ được chuyển vào tài khoản ngân hàng thương mại

• Nhà đầu tư đặt lệnh thông qua các công ty chứng khoán

• Công ty chứng khoán tiến hành xác thực lệnh có hợp lệ hay không

• Công ty chứng khoán gửi lệnh lên sàn giao dịch chứng khoán

• Sàn giao dịch thực hiện khớp lệnh; báo kết quả khớp lệnh về cho công ty môi giới chứng khoán

• Kết thúc phiên giao dịch, sàn giao dịch chứng khoán sẽ báo kết quả khớp lệnh cho trung tâm lưu ký và ngân hàng thanh toán

• Trung tâm lưu ký thực hiện bù trừ giao dịch và yêu cầu ngân hàng thanh toán (hiện giờ đang là BIDV) thực hiện giao dịch.

  • Nói một chút về giao dịch bù trừ (offsetting transaction). Mục đích của nó là để giảm số lượng thanh toán không cần thiết. Ví dụ, nhà đầu tư A bán 10 cổ phiếu. Nhà đầu tư B được khớp để mua 10 cổ phiếu của nhà đầu tư A. Sau đấy B lại bán 6 cổ phiếu, và lại là A mua 6 cổ phiếu đó. Như vậy, sau ngày giao dịch chỉ cần thực hiện 1 thanh toán cho A số tiền bằng 4 cổ phiếu là xong.

• Ngân hàng thanh toán thực hiện chuyển tiền cho các tài khoản ở ngân hàng thương mại, và báo lại cho công ty chứng khoán là đã thanh toán.

Về tổng quan luồng hoạt động là như vậy. Mặc dù mong muốn ban đầu của tôi là trình bày dưới dạng sequence diagram, nhưng tôi không tài nào tìm kiếm được tài liệu đủ rõ ràng để có thể vẽ ra được một quy trình tuần tự được.

Trong bài tiếp theo tôi sẽ quay lại khía cạnh chính, đấy là vấn đề về công nghệ. Để trả lời cho câu hỏi làm thế nào mà hệ thống giao dịch chứng khoán Việt Nam chịu được tải lớn.

Hẹn gặp lại bạn đọc tuần sau.

P/S - Cập nhật ngày 19/05/2024: Thật đáng tiếc khi tôi không thể viết được phần 2 cho chuỗi bài này. Lý do là vì tôi không thu thập đủ tài liệu để viết. Các nguồn mà tôi biết thì đều đã quá cũ, nên có thể không còn đúng với cho thời điểm hiện tại nữa. Nếu có độc giả nào nắm được khía cạnh về công nghệ của hệ thống GDCK, tôi sẽ rất vui nếu được độc giả chia sẻ thêm.

Nắm bắt làn sóng đó, vào tháng 7 năm 2009, ở bang California Mỹ, một nhóm sinh viên ở đại học Harvard đã cùng nhau cho ra đời một nền tảng CDN mới, tên là CloudFlare.

Dù sinh sau đẻ muộn, nhưng CloudFlare đã nhanh chóng chiếm lĩnh thị trường CDN nói riêng và traffic mạng Internet nói chung.

Tính đến năm 2023, có tới 20% traffic trên toàn bộ Internet đi qua hệ thống hạ tầng của CloudFlare. Với số lượng Request Per Second (RPS) lên tới 55 triệu HTTP requests / giây.

Và thật đáng ngạc nhiên khi CloudFlare giải quyết bài toán OLTP (Online Transaction Processing) chỉ với 15 Postgres clusters.

Mỗi cluster gồm ba server. Mỗi server nằm ở một khu vực khác nhau (region) để đảm bảo khả năng recovery khi có disaster.

Vậy CloudFlare đã tuning những gì để Postgres có thể handle một lượng traffic lớn đến như thế, chúng ta cùng bắt đầu tìm hiểu.

1. Connection Pool

Thông thường khả năng xử lý của database thường bị giới hạn bởi các resources có hạn như CPU, Memory.

Một giới hạn nữa là số connections, vì sao vậy?

Trong Postgres, mỗi request từ client tới sẽ tạo ra một process mới. Mà số lượng process cũng là hữu hạn (vì phụ thuộc vào CPU, Memory). Nên số connections cũng là hữu hạn.

Vậy muốn tăng số lượng connections lên nữa thì phải làm sao? Câu trả lời là dùng một connection pool đứng giữa.

Connection pool là một technique thường được dùng để optimize hiệu năng khi số lượng connection vượt quá khả năng handle của server.

PgBouncer, bản chất là TCP Proxy, đứng giữa để quản lý connection từ phía client. Khi này client sẽ tạo connection với PgBouncer thay vì Postgres.

PgBouncer có vài tác dụng chính như:

• Bảo vệ Postgres Server khỏi connection starvation

• Tiết kiệm Postgres Server resource khi reuse connection

• Throttle những câu query chạy quá lâu

2. Bare metal

Để tránh việc phải chạy trên nhiều tầng ảo hoá (virtualization), Cloudflare không chạy Postgres trên môi trường cloud.

Thay vào đó họ chạy các cụm Postgres server trên những server vật lý (Bare metal).

3. HA Proxy làm Load Balancer

Theo lý thuyết thì PgBouncer hoàn toàn có thể đóng vai trò của load balancer. Tuy nhiên, load balancer không phải là tính năng chính nên nếu dùng sẽ không tốt cho hiệu năng (performance).

Do đó, CloudFlare đã dùng HAProxy làm TCP proxy đứng giữa PgBouncer và Postgres server.

Đọc thêm: HAProxy Forwards Over 2 Million HTTP Requests per Second on a Single Arm-based AWS Graviton2 Instance

4. Concurrency

Congestion (tắc nghẽn) là một vấn đề xảy ra với mọi mô hình client-server. Chẳng hạn như TCP, cũng có thuật toán riêng để xử lý tắc nghẽn, gọi là TCP congestion avoidance.

PgBouncer và Postgres Server cũng áp dụng ý tưởng này để xử lý vấn đề tắc nghẽn.

Khi bắt đầu, PgBouncer sẽ tạo một lượng connection pool đủ nhỏ. Sau đó số lượng connection trong pool tăng dần. PgBouncer sẽ đo xem mỗi khi tăng số connection đến với server, thì thời gian phản hồi (Round Time Trip - RTT) có được đảm bảo hay không. Nếu vẫn được đảm bảo, số connection sẽ tăng tiếp, còn không số connection sẽ giảm cho đến khi RTT đạt được con số mong muốn.

5. Ordering Queries

Mỗi câu query tới với PgBouncer sẽ được đưa vào một prioritized queue. Dựa trên yếu tố lịch sử, nếu câu query chạy càng lâu thì độ ưu tiên càng thấp.

Tuy nhiên, sẽ có thể có trường hợp những câu query có độ ưu tiên thấp hơn sẽ không bao giờ được thực thi. Tình trạng này gọi là resource starvation.

Để giải quyết vấn đề này, PgBouncer chỉ enable prioritized queue trong peak traffic. Tức là khi có traffic bình thường thì mọi câu query sẽ đều được execute.

6. High availability

Thông thường khi nói về tính sẵn sàng của một hệ thống (HA - High Availability), thông số đại diện sẽ là uptime - tức thời gian hệ thống up and running.

Khi dùng một SaaS, bên cung cấp dịch vụ sẽ phải đưa ra một cái SLA (Service Level Agreement) để cam kết trong một năm thời gian uptime tối thiểu là bao nhiêu.

Ví dụ, GKE (Google Kubernetes Engine) cam kết thời gian uptime là 99,5%. Điều đó có nghĩa trong một năm, hệ thống của họ “được phép” bị sập khoảng 0,5% x 365d = 1d 19h 28m 8.8s, hoặc mỗi ngày sẽ có thể sập 7m 12s.

Quay trở lại với cụm Postgres cluster của CloudFlare. Họ dùng Stolon để đảm bảo tính HA.

Stolon có vài nhiệm vụ:

• Đảm bảo data sẽ được replicate sang các server trong cùng cluster mà nó đang quản lý

• Thực hiện failover. Tức khi leader database gặp vấn đề, stolon sẽ đứng ra thực hiện election (bầu cử), và chọn ra leader server mới từ nhóm follower server.

Nếu bạn thấy bài viết này hữu ích, hãy nhập email để đăng kí thành viên để không bỏ lỡ những bài viết mới của tôi nhé 💪

Trích dẫn

• Performance isolation in a multi-tenant database environment, blog.cloudflare.com

• CloudFlare internet traffic 2023, theregister.com

• PostgresSQL Scalability, Neokim

Lúc đó, tôi cũng research khá kĩ để xem ERP là gì, nhưng thú thực là tôi cũng chẳng hiểu mấy.

Mãi dạo gần đây, khi có công việc liên quan, tôi mới bắt đầu hiểu nó là cái gì.

ERP (Enterprise Resource Planning)

Để hiểu được ERP là gì thì như cái tên gọi, chắc phải làm ở một enterprise cái đã.

Làm startup thì khó mà động đến cái này, bởi startup có ít người, ít team, và hầu như chỉ xoay quanh chuyện làm phần mềm. Nên nói đến quản lý resource ở startup, ta thường nói đến quản lý scope, cost, và time.

Trong khi đó việc quản lý resource ở một enterprise lại là một câu chuyện phức tạp hơn nhiều. Nào là quản lý chuỗi cung ứng (Supply Chain Management), quản lý khách hàng (Customer Relation Management). Nào là quản lý nhân sự (Human Resource), quản lý tài chính (Financial Accounting). Vân vân và mây mây.

Khi doanh nghiệp bắt đầu phình ra, các phòng ban bắt đầu tăng lên, lúc này có vài lựa chọn.

Một là mạnh ai nấy làm. Phòng nhân sự dùng Google Sheet quản lý danh sách nhân viên. Phòng sales thì xin được budget nên mua một package nhỏ của SalesForce để quản lý khách hàng. Trong khi bên làm phần mềm do biết về công nghệ nên tự cài phần mềm opensource, khỏi xin budget. Tuy nhiên cách này nhìn qua đã thấy là rất hỗn loạn.

Hai là dùng ERP. ERP thường là một phần mềm, all-in-one, miễn phí hoặc trả phí. Tất cả phòng ban chuyển hết qua dùng phần mềm này. Miễn phí thì cần một đội ngũ IT có chuyên môn để setup, maintain. Còn dùng trả phí thì chỉ cần bỏ tiền ra, bên cung cấp dịch vụ lo hết.

Bạn vào link này sẽ thấy danh sách các phần mềm ERP phổ biến hiện tại: https://en.wikipedia.org/wiki/List_of_ERP_software_packages

Nếu danh sách bên trên quá dài, bạn có thể nhớ 8 cái tên dưới đây thôi cũng được:

• Oracle NetSuite ERP for the best all-around ERP software

• Odoo ERP for custom business processes

• SAP Business One for growing companies

• ERPNext for the best value ERP

• Microsoft Dynamics 365 for dynamic use cases

• Acumatica Cloud ERP for the best user experience

• Katana for inventory management

• Sage Intacct for accounting

Frappe - low code platform

Lại để ý danh sách 8 phần mềm bên trên, bạn sẽ thấy ERPNext.

ERPNext được build trên một low-code platform tên là Frappe.

Là một engineer, thú thực tôi không quan tâm mấy đến ERP vì cơ bản nó là một phần mềm tập hợp của các nghiệp vụ khác nhau trong doanh nghiệp. Cái tôi quan tâm hơn là người ta dùng cái gì để làm ra phần mềm ấy.

Frappe có một vài yếu tố làm tôi quan tâm.

Một là Open Source. Frappe có một câu đại ý là “Chúng tôi sẽ cho mấy công ty làm ERP thu phí ra chuồng gà”. Nghe có vẻ hơi drama nhưng mà tôi thích sự tự tin như thế.

Hai là Low-Code. Frappe sẽ lo tất cả các khâu hậu cần để làm một phần mềm, và loại bỏ hầu hết sự lặp lại. Nếu phần mềm chỉ có mấy tác vụ đơn giản, ta không cần phải code, tức no-code. Còn nếu phức tạp hơn chút, thì cũng chỉ cần quan tâm đến những phần quan trọng, tức low-code.

Ba là tính Flexible. Với Frappe và một chút thời gian, bất kì ai cũng có thể build ra một phiên bản ERP cho riêng họ. Hay như trang https://frappe.school này, nó được build hoàn toàn từ Frappe.

Tạm kết

Trong một bài viết cũ về learning framework, tôi có nhắc đến việc tôi muốn nâng cấp khả năng học của mình lên từ mức độ cao hơn như là đi dạy cái mình đã biết.

Công cụ để hiện thực hoá việc dạy đó lúc trước là Udemy, còn bây giờ thì đã có thêm Frappe.

Đầu tiên, ta cần tạo một kafka topic mới với partitions = số kafka broker * hệ số tự chọn. Nếu số kafka broker là 3, và bạn chọn hệ số là 4, thì sẽ tạo topic với partitions là 12. Lưu ý con số 12 cũng là số lượng maxReplica mà Keda sẽ scale lên trong quá trình autoscale.

./kafka-topics.sh --create --topic kafka-test-topic --partitions 12 --replication-factor 1 --bootstrap-server kafka.kafka:9092

Sau khi tạo được topic, việc cần làm là produce message vào trong topic đó. Ta có thể sử dụng thư viện opensource kafkacat để phục vụ mục đích trên. Bên dưới là định nghĩa của một Deployment sử dụng kafkacat.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kafkacat-producer
  namespace: keda
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kafkacat-producer
  template:
    metadata:
      labels:
        app: kafkacat-producer
    spec:
      containers:
        - name: kafkacat-producer
          image: confluentinc/cp-kafkacat
          command:
            - "sh"
            - "-c"
            - |
              for i in $(seq 1 1000); do
                echo "Message $i" | kafkacat -b kafka.kafka:9092 -t kafka-test-topic -P
                sleep 0.1
              done
          resources:
            limits:
              cpu: 100m
              memory: 50Mi

Tiếp theo ta cần tạo consumer.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kafkacat-consumer
  namespace: keda
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kafkacat-consumer
  template:
    metadata:
      labels:
        app: kafkacat-consumer
    spec:
      containers:
        - name: kafkacat-consumer
          image: confluentinc/cp-kafkacat
          command:
            - "sh"
            - "-c"
            - "kafkacat -b kafka.kafka:9092 -G kafka-test-consumer-group kafka-test-topic"
          tty: true

Bước cuối cùng là tạo ScaledObject để Keda biết rằng cần phải scale deployment nào (scaleTargetRef.name), và scale dựa vào input nào (metadata.lagThreshold).

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafkacat-consumer-scaledobject
  namespace: keda
spec:
  scaleTargetRef:
    name: kafkacat-consumer
  pollingInterval: 30
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka.kafka:9092
      consumerGroup: kafka-test-consumer-group
      topic: kafka-test-topic
      lagThreshold: "10"
      offsetResetPolicy: latest

Nếu như các bước setup không có vấn đề, kafka consumer giờ đây đã autoscale dựa trên số lag threshold!

Hãy tăng giảm số lượng replicas của producers để theo dõi sự tăng giảm tương ứng của consumers.

Nếu bạn dùng K8S hằng ngày, chắc chắn pod và service là hai resource bạn bắt gặp nhiều nhất. Trong bài viết này, chúng ta cùng nhau tìm hiểu cách thức pod và service hoạt động.

Khi tạo một Service, có hai thông tin bắt buộc phải được định nghĩa

1. selector, để chỉ ra service này sẽ trỏ đến pod nào

2. targetPort, là port của pod dùng để nhận traffic

Dưới đây là một ví dụ về cách define service:

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 3000
  selector:
    name: app

Khi chạy lệnh “kubectl apply -f service.yaml”, K8S sẽ tìm tất cả các pod có label trùng với selector của service (name:app), và thu thập tất cả IP Address của các pod đó.

Tiếp đến, với mỗi IP Address thu thập được, K8S sẽ tạo ra một endpoint tương ứng.

IP address + port = endpoint
---------------------------------
10.0.0.3   + 3000 = 10.0.0.3:3000

Như vậy có bao nhiêu pod có label match selector, thì có bấy nhiêu endpoint được tạo. Đến đây, tôi mới đặt câu hỏi, tại sao lại cần phải có endpoint? Rõ ràng nếu endpoint chỉ là tổ hợp của IP Address và Port, thì rõ ràng là chỉ cần Service và Pod là đã đủ rồi.

Hoá ra mối quan hệ giữa service và pod không phải là 1-n như tôi nghĩ, mà là quan hệ n-n. Tức một service có thể gắn với nhiều pod, và ngược lại, một pod có thể gắn với nhiều service. Do đó cần phải có một resource trung gian, đó chính là endpoint.

Endpoint được dùng vào những việc gì

Endpoint được dùng trong một số thành phần của k8s như

• kube-proxy

• ingress-controller

• network policy

Kube-proxy là thành phần dùng để mapping Service IP Address sang Pod IP Address. Việc mapping từ IP này sang IP khác như vậy người ta gọi là NAT. Cụ thể hơn trong kube-proxy, việc đổi IP Address của destination, được gọi là DNAT.

Để thực hiện việc mapping, kube-proxy sử dụng iptables của Linux. Chạy câu lệnh dưới để xem những resources liên quan đến kube-proxy.

kubectl get all -n kube-system | grep proxy

Khi thực hiện xoá pod. Luồng logic sẽ như sau:

1. Chạy câu lệnh “kubectl delete pod A”

2. Request được gửi đến API server

3. API Server forward request đến Endpoint Controller

4. Endpoint Controller báo lại cho API server rằng cần remove endpoint của pod A ra khỏi list

5. API Server remove endpoint của pod A ra khỏi etcd

6. API Server báo cho kubelet ở node mà có pod vừa mới bị xoá endpoint

7. kubelet báo cho kube-proxy, CoreDNS, Ingress Controller, vv rằng endpoint của pod A đã bị xoá

8. kube-proxy nhận được thông báo, liền xoá các mapping của service với pod A ra khỏi iptables

Đến bước này bất kể request nào đến service được với pod A đều sẽ fail, vì không tìm thấy trong iptables nữa. Tuy nhiên, đến đây tôi mới đặt câu hỏi: Nếu Service trỏ đến nhiều pod, và mỗi pod lại nằm ở những node khác nhau thì có chuyện gì xảy ra hay không?

Điều gì xảy ra khi thực hiện một request đến một K8S service

Thực ra K8S service không hề tồn tại. Thứ mà bạn thấy Service IP Address cũng chỉ là virtual IP, tức không có bất kì một process nào listen trên IP và port của Service.

Giả sử có 2 pod A và B, được deploy trên 2 node khác nhau nodeA, nodeB. Cả 2 pods được trỏ vào bởi 1 service duy nhất, gọi là S. Giờ đứng ở một pod nào đó trong nodeC, thực hiện một request đến service S, chuyện gì sẽ xảy ra?

1. Client thực hiện một DNS query đến kube-dns

2. kube-dns trả về virtual IP của Service

3. client thực hiện request đến virtual IP của Service

4. kube-proxy ở source node thực hiện DNAT (ServiceIP → Destination PodIP)

5. kube-proxy forward request đến Pod IP

6. Pod nhận request và trả về response

7. kube-proxy ở source node thực hiện SNAT (Destination PodIP → ServiceIP)

8. Response trả về cho client

Nếu suy ngẫm một chút ở bước 4, ta sẽ có thể đặt một câu hỏi là: Vậy phải chăng kube-proxy ở mỗi node sẽ phải lưu toàn bộ thông tin của tất cả các Pod? Để trả lời câu hỏi này, tôi vào trong pod kube-proxy và log ra toàn bộ các action trên iptables

kubectl exec -it kube-proxy-pod-name -- sh -c "iptables-save"

Trong phần log được in ra, có thể thấy cả những update của các endpoint, hoặc service gắn với pod nằm trên node khác.

Ở giữa bước 5 và bước 6, tôi có thắc mắc là việc giao tiếp giữa 2 node khác nhau được thực hiện ra sao, câu trả lời là đó là phần việc của CNI.

Ở phần trước chúng ta đã lấy một vài ví dụ về các metrics liên quan đến productivity của developer như sự phân bổ về số lượng commits, số pull requests theo từng tháng, hay trung bình thời gian coding. Trong phần này, tôi sẽ tiếp tục mang đến thêm một vài ví dụ về cách đo lường productivity cho các role khác như Product Manager, QA Engineer, hay cả một team.

Issue Throughput

Nếu request throughput có thể phần nào nói lên được hiệu năng của một application, thì issue throughtput cũng phần nào miêu tả được hiệu suất của một team.

Bên trên là ví dụ về tỉ lệ jira issue được hoàn thành của một team. Có thể thấy con số chỉ rơi vào khoảng 66%. Tức nếu có 10 issue được viết ra, thì chỉ có từ 6-7 issue được đưa về trạng thái complete. Nhiệm vụ của các product manager nói riêng và cả team nói chung là là cần phải tìm ra được nguyên nhân vì sao tỉ lệ đó lại bị thấp như vậy.

Bug Age

Còn đối với team QA/QC, thông số về thời gian kể từ khi phát hiện ra bug cho đến khi bug được fix sẽ được quan tâm hơn cả. Ví dụ bên dưới cho ta thấy tuần vừa qua team QA/QC đã phát hiện ra 5 bug mới, cả 5 bug đó đã đều được fix. Trung bình mỗi bug mất khoảng gần 5 ngày để được chuyển trạng thái thành fixed.

Ngoài ra, biểu đồ về số lượng bug tính theo tuần cũng có ích khi ta có thể biết được trong khoảng thời gian nào sản phẩm có nhiều lỗi. Từ đó có thể điều tra nguyên nhân và đúc rút bài học cho tương lai.

DORA và SPACE

Những ví dụ trên và cả những ví dụ trong phần 1 của bài viết đều là những metric rời rạc, nếu chỉ dựa vào từng metric và đưa ra đánh giá sẽ có phần phiến diện. Do đó, người ta chọn ra một số metrics, và tổng hợp lại thành những framework, sao cho cuối cùng những đánh giá đó là công tâm và khách quan nhất.

DORA và SPACE là hai framework tiêu biểu.

Ngày thứ 8 của tháng “adventofsharing” trên Slack cộng đồng WeBuild có bài viết giới thiệu về chủ đề “Developer Productivity”. Nhân tiện tôi cũng đang hỗ trợ dựng lên một hệ thống phục vụ nhu cầu tương tự, nên sẽ viết thêm để bổ sung ý cho bài viết đó. Dưới đây là bài viết gốc.

#adventofsharing Bàn về developer productivity

Năng suất lao động (productivity) luôn là một chủ đề được quan tâm. Từ thời tiền sử sống trong xã hội bầy đàn, tiến lên xã hội hiện đại với cách mạng công nghiệp; rồi gần đây hơn là thời đại của máy tính, internet, block chen, AI,... loài người luôn ám ảnh với việc làm được nhiều hơn, sản xuất nhiều hơn, nhanh hơn. Ngành phần mềm cũng không phải ngoại lệ. Vậy productivity trong ngành phần mềm được định nghĩa như thế nào? Câu hỏi nghe đơn giản nhưng câu trả lời lại khá phức tạp. Một research gần đây [1] tại Microsoft cho thấy developer có xu hướng nghĩ về input: số bug/task đã hoàn thành, số lượng commit, thời gian tập trung cho deep work, thời gian teamwork khi được hỏi về productivity. Trong khi các manager có xu hướng tập trung vào output như performance, velocity, cũng như chất lượng của sản phẩm được tạo ra. Và nếu bạn hỏi những người ở vị trí non-tech như CEO, CFO, khả năng cao họ chỉ quan tâm team phần mềm làm được ra bao nhiêu tiền và đốt bao nhiêu vào quỹ lương.

Như rất nhiều thứ khác trong ngành phần mềm, it depends. Sẽ không thể tìm được một câu trả lời chung nào cho định nghĩa về productivity để áp dụng cho tất cả các team. Vậy thì các công ty phần mềm lớn nhỏ ngoài kia họ đang làm thế nào để đo lường productivity, hãy điểm qua một số cách thông thường.Cách thứ nhất: không làm gì cả. Nghe có vẻ hơi anti-pattern, nhưng khá phổ biến ở các team nhỏ, ở những team này manager có thể nắm khá rõ về khối lượng công việc cũng như output của từng thành viên, cũng như của cả team, việc cụ thể hóa thành con số không có nghĩa lý và ít mang lại hiệu quả. Cách thứ hai: vậy team lớn thì họ dùng gì, hiện tại trong giới có hai tiêu chuẩn khá nổi là DORA [2] và SPACE [3]. DORA đề ra bốn metric cho một engineering team, focus chính vào việc delivery phần mềm.

• Deployment Frequency – tần suất release lên production.

• Lead Time for Changes – thời gian dành ra từ khi bắt đầu đến khi release của ticket.

• Change Failure Rate – tỉ lệ các release tạo lỗi trên production.

• Time to Restore Service – thời gian để fix production khi có release lỗi.

Trong khi SPACE đề ra năm tiêu chí:

• Satisfaction and wellbeing: mức độ hạnh phúc và thỏa mãn của các thành viên trong team.

• Performance: chất lượng đầu ra của sản phẩm.

• Activity: số lượng output/task hoàn thành.

• Communication and collaboration: mức độ teamwork và collab giữa các thành viên trong team.

• Efficiency and flow: thời gian focus vào deep work của team.

Điểm cộng của DORA là các metric được định nghĩa rõ ràng, điểm trừ là tập trung quá nhiều vào việc delivery và hoàn toàn bỏ qua yếu tố con người. Team của mình hiện tại cũng đang dùng DORA và tác dụng khá hạn chế, khó nêu được điểm yếu cần cải thiện, và các metric khá dễ bị game, có thể dẫn đến phản tác dụng.
SPACE được ra đời để khắc phục nhược điểm của DORA, đề cao input và yếu tố con người, nhấn mạnh việc lấy survey từ các thành viên trong team, nhưng nhược điểm lại là các metric phức tạp, mơ hồ và cũng khó đo đạc báo cáo.

Cách thứ ba: tự đặt ra metric riêng cho mình, thường được áp dụng ở các big tech, ví dụ như Uber [4], Meta, Amazon đề cao số lượng diff (commit),  Linkedin [5] dùng top-down approach, bắt đầu với ba key metric Efficiency, Effectiveness, Happiness sau đó đi sâu vào và mở rộng ra các key metric nhỏ hơn như time to review, user satisfaction score, commit to publish time, etc. Việc xây dựng hệ thống để thu thập và báo cáo số liệu thường được đảm nhiệm bởi một team gọi là Developer Experience.

Tạm kết ở đây đã vì chủ đề này phức tạp và nếu nói nữa thì chắc phải viết cả series, bài viết cũng chỉ nhằm mục đích giới thiệu những khái niệm cơ bản ở bề mặt. Tóm lại thì mình thấy nhu cầu đo đạc productivity là chính đáng, tuy nhiên đo thế nào và đo cái gì là bài toán các team phần mềm sẽ phải tự tìm cho câu trả lời của riêng mình. Hãy nhớ rằng đằng sau các metric và con số là những con người, họ cũng có buồn vui hỉ nộ ái ố, và những con số thì khó có thể model hết hành vi của con người.

[1] https://arxiv.org/pdf/2111.04302.pdf

[2] https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

[3] https://queue.acm.org/detail.cfm?id=3454124

[4] How Uber Is Measuring Engineering Productivity

[5] LinkedIn Engineering Efficiency

Peter Drucker, cha đẻ của ngành quản trị kinh doanh từng nói rằng thứ gì không đo đạc được thì không thể cải thiện được. Điều này có thể không đúng với từng cá nhân, khi có nhiều thứ thuộc về cảm giác là không thể đo đạc nhưng vẫn có thể cải thiện. Tuy nhiên với một tổ chức hay một doanh nghiệp, đo đạc là việc bắt buộc phải làm nếu những người quản lý muốn biết được những sự thay đổi sẽ đem lại kết quả ra sao.

Trở lại với bài viết ban đầu, ta có thể thấy được một bức tranh toàn cảnh về chủ đề Developer Productivity . Tuy nhiên, tác giả bài viết cũng đã nói rằng đó mới chỉ là những khái niệm rất cơ bản ở bề mặt. Còn rất nhiều chi tiết ở đi sâu vào bên dưới chưa được khai thác tới. Và trong bài viết dưới đây, tôi sẽ đi vào phần thực hành, khi cho các bạn thấy hình hài của những khái niệm trên trông sẽ như thế nào.

Giới thiệu về Devlake

Devlake là một mã nguồn mở giúp thu thập và xử lý data từ nhiều nguồn khác nhau. Các nguồn đó có thể kể đến như Github, Gitlab, Jira, Trello, vv. Từ nguồn data đó, ta có thể visualize thành các bảng biểu, các metric, giúp cho quá trình phát hiện và cải thiện các vấn đề liên quan đến productivity trở nên trực quan. Dưới đây là hình minh hoạ cách thức Devlake hoạt động.

Sau khi tiến hành config các nguồn dữ liệu, Devlake sẽ đi thu thập data và lưu chúng vào trong một relational database. Tiếp đó các phần mềm visualization như Grafana sẽ đọc data từ database ra và hiển thị thành các biểu đồ.

Một vài ví dụ tiêu biểu

Lấy một ví dụ như biểu đồ bên dưới, biểu thị sự phân bổ số commits của các thành viên vào các ngày trong tuần. Dựa vào biểu đồ ta dễ nhận thấy thứ ba có vẻ là ngày mà các anh dev hoạt động năng suất nhất. Thứ hai năng suất kém hơn cả thứ năm, cũng dễ hiểu vì thường đầu tuần sẽ phải họp hành nhiều. Trong khi thứ 6 là ngày có ít commit nhất, có thể là do những phần việc quan trọng thì đã được hoàn thành từ các ngày trước đó. Chỉ từ một thông số đơn giản, ta đã có thể suy ra được một số insights khá là thú vị.

Ví dụ trên nghe có vẻ thú vị, nhưng chưa cho ta thấy điều gì cần phải cải thiện. Dưới đây là một ví dụ khác về số lượng Pull Request (PR) mới được tạo hằng tháng. Qua biểu đồ ta thấy tháng 10, lượng PR giảm một cách đáng kể so với các tháng trước đó, vậy nguyên nhân là do đâu? Hoá ra tháng 10 có một project mới và các developer đã tập trung vào việc làm cho xong bản MVP nên đã không tạo PRs. Việc code không được review cẩn thận có thể gây ra những tech debt không mong muốn sau này, do đó cần có những cải thiện về mặt quy trình trong yêu cầu tạo PR cho những dự án mới tiếp theo. Bạn thấy đấy, có đo đạc vẫn hơn phải không.

Tiếp theo là một metrics về coding day của các developers. Có thể thấy thời gian thực tế một developer ngồi và code chỉ chiếm khoảng 40% tổng thời gian của họ khi đi làm. Tức một ngày đi làm 8 tiếng thì chỉ tầm 3 tiếng là dành để ngồi code, thời gian còn lại sẽ dành cho những việc khác như làm làm rõ requirements, họp hành, hay bảo trì hệ thống. Nếu phần trăm coding days bị quá thấp, hoặc quá cao, thì team cũng sẽ cần phải tìm hiểu nguyên nhân vì sao và từ đó có những action phù hợp.

Trên đây là một vài ví dụ về các metric dùng để đo đạc hiệu suất làm việc của các developer. Tuy nhiên trong một team làm sản phẩm, còn rất nhiều những role khác như Product Manager, QA, Designer, vv. Vậy làm sao để đo đạc được hiệu suất làm việc của các thành viên đó. Trong phần hai, tôi sẽ giới thiệu thêm một vài ví dụ tiêu biểu để trả lời cho câu hỏi trên.

Lúc trưa đi ăn, mấy đồng nghiệp có nói chuyện về sự khác nhau giữa client-side rendering và server-side rendering, và vì sao NextJS lại không giống PHP, dù nghe qua thì có vẻ là cơ chế hoạt động giống nhau. Là một người ngoại đạo chưa làm frontend bao giờ, nhưng nghe chủ đề thú vị nên tôi cũng muốn thử tìm hiểu xem sao.

https://vercel.com/blog/understanding-react-server-components

Để có thể hiểu sâu sắc về một thứ gì đó, không gì tốt hơn việc điểm lại những sự kiện lịch sử phát trển của nó. Tôi có hai bài bài thuyết trình về chủ đề “Lịch sử Internet” và “Lịch sử Computer Chip”, cũng đề cập về kha khá các mốc sự kiện đáng chú ý trong lịch sử phát triển của nghành IT chúng ta. Nếu có thời gian rảnh, mời bạn đọc ghé xem thử.

Quay trở lại chủ đề chính, cùng xem để có được sự đa dạng các frontend framework như hiện nay, thì thế giới đã trải qua những giai đoạn nào:

1993 - 1996: Chỉ một tình yêu chỉ một HTML

Đây là giai đoạn đánh dấu những viên gạch đầu tiên được xây, đi cùng với sự ra đời của trang web đầu tiên, browser đầu tiên, và HTML. Lúc này Javascript còn chưa ra đời, CSS cũng thế, nên các trang web đều hiển thị dưới dạng thuần HTML. Bên dưới là website đầu tiên trên thế giới, viết bởi Tim Bernes-Lee tại viện khoa học CERN, vẫn còn tồn tại đến ngày nay.

https://info.cern.ch/hypertext/WWW/TheProject.html

1996-2000s: Javascript ra đời

Javascript ra đời trong thời gian này, viết bởi ông Brendan Eich khi ông đang làm việc cho Netscape (cũng là một trong những browser đầu tiên). Javascript ban đầu được tạo ra với cái tên là LiveScript, nhưng vì lúc bấy giờ Java đang là ngôn ngữ hot, nên LiveScript đã đổi tên thành JavaScript để được chú ý hơn. Có bài nói chuyện của Lex Fridman và Brenden Eich ở đây.

Năm 1996, Internet Explorer của Microsoft cũng ra đời. Sau đó 3 năm thì họ giới thiệu XMLHttpRequest. Công nghệ này cho phép data được fetch về asynchronous. Đến đây tôi có thắc mắc rằng “javascript là single-threaded language”, vậy làm sao mà XMLHttpRequest có thể chạy async được? À thì hoá ra là do phần callbacks sẽ được browser lưu ở một chỗ khác, và khi callback đó có kết quả, single-threaded kia sẽ quay lại và execute cái callback đó.

2000s - 2010s: Ajax và jQuery

XMLHttpRequest cải tiến thành Ajax, và sau đó là jQuery. Bài giới thiệu về Ajax viết năm 2005 vẫn còn đến ngày nay.

2010s-2015s: Javascript framework

Bắt đầu với sự ra đời của 3 framework lớn, đó là BackboneJS, KnockoutJS, và AngularJS.

Angular là sản phẩm của Google. Angular 1 gây được tiếng vang lớn và được sử dụng rộng rãi. Nhưng do Angular 2 ra đời mà lại không tương thích với Angular 1, nên một lượng lớn lập trình viên đã cảm thấy không còn muốn gắn bó với Angular nữa.

Đúng lúc này, năm 2013, React của facebook ra đời. Và gần như ngay lập tức framework này chiếm lĩnh thị trường.

2016-2020: GraphQL ra đời, Next.js ra đời

Cùng vơi sự phát triển như vũ bão của các công nghệ mới. Next.js đã đời trong thời kì này.

Deno đang dần thay thế Node.js?

Còn về SPA và MPA thì sao?

Single Page Application (SPA) giống như client-side rendering

Multiple Page Application (MPA) lại giống như server-side rendering

Vì sao NextJS lại không giống PHP?

Thực ra câu chuyện một công nghệ ra đời, sau đó khoảng vài năm, người ta mới nhận ra công nghệ đó không phù hợp là chuyện chẳng hiếm gặp. Ví dụ có thể kể đến câu chuyện về SQL. Cứ dăm ba năm sẽ có một ngôn ngữ truy vấn nào đó ra đời, nói rằng ưu việt hơn SQL. Nhưng rồi đã gần 40 năm qua, SQL vẫn là lựa chọn không thể thay thế. Hay câu chuyện về PHP, cứ 5 năm, sẽ có một ai đó hỏi một câu đại loại như: “Trong vòng 5 năm tới, PHP có còn ai dùng nữa không?”, dĩ nhiên vẫn rất nhiều người đang dùng PHP và sẽ còn dùng PHP.

Tuy nhiên những công nghệ mới ra đời không phải chỉ để cho vui. Chúng ra đời để giải quyết những vẫn đề mà công nghệ cũ không giải quyết được. Ví dụ như câu chuyện của Deno được sinh ra để giải quyết một số vấn đề không thể giải quyết được của NodeJS.

NextJS cũng vậy, nó có một số tính năng mà PHP không có, nó phục vụ những usecases riêng. Cụ thể thì khi nào dùng NextJS?

• Nếu cần cải thiện SEO

• Nếu team hiện tại đang dùng React ở phía frontend

• Nếu web yêu cầu tính tương tác cao với người dùng

• Nếu muốn nâng cao developer experience (code không bị cáu)

Git được viết bởi ông Linus Torvalds, cũng là người đã viết ra phiên bản đầu tiên của nhân hệ điều hành Linux. Linus nổi tiếng là người nóng tính. Có lần ngay trên sóng truyền hình, không biết vì lý do gì ông nhìn thẳng vào camera, giơ ngón giữa lên và nói: “Nvidia, Fuck You!”. Hay có lần khác, trong lúc review code ông comment rằng: “This piece of code is pure and utter shit. It makes me go to bed wanting to kill myself”, mời bạn đọc tự dịch.

Git ra đời năm 2005, vậy trước đó người ta dùng gì?

Phần mềm đầu tiên dùng để quản lý code được ghi nhận tên là Source Code Control System (SCCS). Phần mềm này được phát triển ở Bell Labs cuối năm 1972 để phục vụ cho quá trình phát triển hệ điều hành Unix.

Những phần mềm tiếp theo ra đời để cải tiến những nhược điểm của SCCS có thể kể đến như Revision Control System (1982), Concurrent Versions System (1986).

Tiếp đến là một cái tên quen mặt hơn đó là Subversion (SVN), được phát triển vào năm 2000, và hiện giờ thì đang được quản lý bởi Apache Foundation.

SVN cũng huy hoàng được khoảng 5 năm trước khi git của Linus Torvalds ra đời. Và kể từ ấy trở đi không thấy có phần mềm nào nổi lên để thay thế git nữa.

Git có nhiều tính năng, nhưng nếu mà nói sử dụng thường xuyên chắc chỉ loanh quanh cỡ 5 câu lệnh:

# khởi tạo 
git init

# chọn files để commit 
git add <file>

# commit
git commit -m "<commit message>"

# đẩy code đi đâu đó
git push origin <branch>

# lấy code ở đâu đó về 
git pull origin <branch>

Có người làm biếng đặt cả alias, để mỗi khi cần push, pull, commit, hay checkout thì chỉ cần gõ vài chữ là xong.

alias gck='git checkout'
alias gpo='git push origin HEAD'
alias gpl='git pull --rebase'
alias gs='git status'
alias gbr='git branch'

Dĩ nhiên sẽ có những vẫn đề phức tạp hơn mà mấy câu lệnh phổ biến bên trên không giải quyết được. Một trong số đó là nhu cầu về việc dọn dẹp commit.

Giả sử có hai nhánh: main và new-feature. Nhánh new-feature được tạo ra từ nhánh main. Trong nhánh new-feature có 3 commits theo thứ tự như sau:

• Init new feature code

• Add some configs

• Finish new feature

Giờ muốn merge nhánh new-feature vào nhánh main thì dễ rồi.

$ git checkout main
$ git merge new-feature
$ git log
6ba01da Finish new feature
f67273e Add some configs
dc1f2dd Init new feature code
12783dd Finish MVP
c6fc165 Init commit

Sau khi merge xong thì nhánh main giờ sẽ có đủ cả 5 commits, 2 có từ trước, và 3 được merge từ new-feature.

Có một nhu cầu ở đoạn merge này, đấy là làm sao để gom tất cả các commit trong nhánh new-feature thành 1 commit duy nhất trong nhánh main. Ở nhánh new-feature có thể có rất nhiều commit do lập trình viên thử nghiệm đủ thứ, sửa đủ thứ. Khi merge lại vào nhánh main, thì nhìn lịch sử commit sẽ rất hỗn độn.

Trong trường hợp này người ta dùng một tính năng gọi là squash, tức sẽ gom nhiều commits lại thành một commit duy nhất.

$ git checkout main
$ git merge --squash new-feature
$ git commit -m "Add new feature"
$ git log
3d33fd3 Add new feature
12783dd Finish MVP
c6fc165 Init commit

Lúc này mấy file bên nhánh new-feature sẽ được “git add” vào nhánh main, và sau git add, dĩ nhiên là “git commit” những file đó lại, kết thúc quá trình squash. Sau quá trình này, nhánh main chỉ còn 3 commits, trông gọn hơn nhiều.

Tuy nhiên dùng squash đồng nghĩa với việc xoá toàn bộ lịch sử commit ra khỏi nhánh main. Điều này đôi khi lại không được khuyến khích. Bây giờ giả sử bên nhánh new-commit, ta muốn bỏ đi một số commit, nhưng muốn giữ lại một số commit thì phải làm sao?

Câu trả lời là dùng “git rebase”. Nếu dịch từng từ thì có thể hiểu như sau: “re” nghĩa là làm gì đó lại, “base” là gốc, “rebase” là “làm lại gốc”, tức có thể hiểu là chỉnh lại các commits.

$ git checkout new-feature
$ git rebase -i <commit_hash>
$ git rebase --continue

Để bắt đầu rebase, thì ta cần chọn một cái “base” để có thể “re”, tức là chọn một cái commit trong quá khứ để thực hiện lại việc tinh chỉnh commit. Sau khi chạy lệnh “rebase -i”, danh sách các commit sẽ được hiện ra với các lựa chọn mà ta có thể làm với một commit cụ thể. Các lựa chọn đó rất đa dạng, từ việc đơn giản như sửa lỗi typo của một commit message (reword), đến việc sửa lại code (edit), từ việc xoá đi một commit (drop), cho đến việc squash nhiều commit lại với nhau (squash), vv.

# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#    commit's log message, unless -C is used, in which case keep only #.   #    this commit's message; -c is same as -C but opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --
#    continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#    create a merge commit using the original merge commit's
#    message (or the oneline, if no original merge commit was
#    specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#    to this position in the new commits. The <ref> is
#    updated at the end of the rebase

Người dùng Tmux thường sẽ không dùng nút prefix mặc định Ctrl + a, vì rõ ràng như vậy rất tốn công khi phải bấm giữ hai phím cùng một lúc. Dùng duy nhất một nút prefix rõ ràng tiện lợi hơn nhiều. Thường phím nào ít được dùng nhất mà lại tiện gõ nhất thì sẽ được chọn để làm nút prefix.

Ai có thắc mắc là cách đổi default prefix như nào thì đơn giản chỉ cần vào file config của tmux đổi mấy dòng sau là được:

> vim ~/.tmux.conf
set -g prefix `
unbind C-a
bind ` send-prefix

Nếu là dân IT, thì dùng bàn phím cơ là một trải nghiệm cũng đáng để thử. Tiếng gõ lách tách và cảm giác gõ phím nhẹ nhàng nhiều khi làm cho công việc cũng trở nên thích thú hơn. Hoặc nếu lười viết blog quá thì mua một bàn phím cơ cũng là một cách khắc phục hiệu quả.

Nhưng có một vấn đề. Đấy là mấy bàn phím cơ thường không có phím backtick. Vậy phải làm sao bây giờ?

Cách đơn giản nhất là đổi prefix từ backtick sang một phím khác. Trong các phím ở góc trái trên của bàn phím, chắc chỉ có caps_lock là phím ít được dùng hơn cả, mà vị trí của nó cũng rất thuận lợi cho cho ngón út có thể bấm được. Tuy nhiên cách này sẽ phải hy sinh chức năng của phím cap_locks, nghĩa là nếu dùng tmux thì không dùng được phím caps_lock như bình thường. Hoặc nếu muốn dùng thì phải bấm hai lần.

Cách tốt hơn đấy là đổi phím caps_lock sang một phím khác còn ít sử dụng hơn, hoặc chẳng mấy khi sử dụng, ví dụ như phím home. Cách để đổi chức năng của các phím như vậy trong ngành chơi phím người ta gọi là “custom keymap”. Để custom được keymap thì có thể dùng phầm mềm. Ví dụ như phần mềm tên là Karabiner-Elements nhìn số sao trên Github thấy rất uy tín. Phầm mềm này cài và dùng đều dễ. Cuối cùng chỉ cần cài đặt thế này là đã có thể đổi được chức năng của hai phím home và caps_lock rồi.

Bước cuối cùng là đổi lại config trong tmux từ phím backtick về phím home.

> vim ~/.tmux.conf
set -g prefix Home
unbind C-a
bind Home send-prefix

Và reload lại config của tmux là xong!

tmux source-file ~/.tmux.conf